kuscadev | Minimal. Practical. Worth Sharing.

What is Network Topology?

Thu, 02 Apr 2026 00:00:00 GMT

What is Network Topology?

Simply put, network topology can be defined as the arrangement of the various components of a computer network. It is possible to classify network topologies under two headings: physical topology and logical topology. In this article, I will generally talk about physical topology types, but first, let’s briefly touch upon logical topology.

What is Logical Topology?

Logical topology refers to the type of topology that shows how network devices establish communication with each other and how data is transferred within the network.
Now that we have covered logical topology, we can return to our main subject: physical topology.

What is Physical Topology?

Physical topology is the concept used when talking about the peripherals and physical connection methods used while creating the network. The type of cable used in the structure of the network and the devices used in the network are specified in this topology. We can list the physical topology types as bus, ring, star, extended star, mesh, point-to-point, and tree topologies.
Let’s examine these topology types one by one.

Bus Topology

In a bus topology, all devices are connected to a single backbone. Coaxial cable is typically used in this backbone. In bus topology, the signal travels through all devices. Devices check the incoming signal and, if the signal address is relevant to them, they process the signal; otherwise, they remain passive and release the signal.
In cases where the coaxial cable used is thin, the maximum line length is 185 meters, and in cases where it is thick, it is 500 meters.
A maximum of 30 devices can be connected to the network, and there are terminators at both ends of the backbone. Since the signal travels through all devices on the line until it reaches the target device, network performance is low.
To summarize bus topology;

Advantages:

The network is easy to set up.
It is easy to add new devices to the network.
It is economical.
Since all devices are lined up on a single backbone, cable usage is low.
No Switch/Hub is required.

Disadvantages:

The number of devices that can be connected to the network is limited.
Line length is limited. (185 meters for thin cable, 500 meters for thick cable.)
Any problem occurring in the backbone affects the entire network.
It is difficult to identify and resolve problems.
Bandwidth is low.
Every new device added decreases network performance.

Ring Topology

In a ring topology, as the name suggests, all devices are connected to each other in the form of a ring. The sent data visits all devices one by one until it reaches the receiver. Signals are transmitted unidirectionally from one device to another. In other words, each device is a receiver for the previous device and a sender for the next device. Since the incoming signal is regenerated at each unit, signal attenuation is at the lowest level.
Data on the network is sent with a 3-byte packet called a “token.” This packet circulates through all devices until it reaches the receiver. In a ring topology, there is a MAU (Multistation Access Unit) at the center.
Considering a network consisting of 50 devices, data sent from the first device to the last device will reach the receiver after visiting 49 devices one by one.
To summarize ring topology;

Advantages:

There is no need for any server.
All devices in the network have the same authority.
Expanding the network has a low impact on performance.
It is easy to set up.
The probability of collision is minimal in these types of topologies.

Disadvantages:

The cost is high because the amount of cable used is high and the MAU is expensive.
A failure in any of the devices affects the entire network.

Star Topology

It is the type of topology created by connecting each device to a switch or hub located at the center. Data coming from the sender first goes to this central switch or hub, and from there, it is transmitted to the receiving device.
It is the most common topology type used today. The connection between devices is provided by twisted pair cables. The distance of the devices connected to the network to the hub or switch can be a maximum of 100 meters. In cases where this length is exceeded, significant drops in performance occur.
To summarize star topology;

Advantages:

It is easy to add new devices to the network.
It is easy to detect a problem occurring in the network.
A failure in any of the connected devices does not affect the rest of the network.
Its structure and understanding are quite simple.

Disadvantages:

Any failure in the central hub or switch affects the entire network.
Cable usage is high compared to other topologies.

Mesh Topology

In mesh topology, every device in the network is directly connected to all other devices. It is mostly used between Wide Area Networks (WAN). In a scenario where the number of devices connected to the network is $N$, the number of connections on the network is $N(N-1)/2$.
Since every device establishes a connection with every other device, if any connection in the network is broken, data can reach the receiver using other connections.
There are two types: full mesh and partial mesh. In full mesh, all devices establish direct connections with each other, while in partial mesh, there are cases where a device does not establish connections with all other devices.
The main prominent features of this topology can be listed as scalability, flexibility, robustness, and consistent data transfer. In addition, the fact that there is no need for any center in this topology is another one of its prominent features.
To summarize mesh topology;

Advantages:

Any failure in one of the devices does not affect the network in general.
Data transmission speed is quite high.
In cases where the network needs to be expanded, it is easy to add new devices to the network because other connections are not affected.

Disadvantages:

It has a complex structure due to the very high number of connections.
Since every device is connected to each other, a lot of cable is required; naturally, the cost is high.

Point-to-Point Topology

It is the most basic topology consisting of one receiver and one sender. In this topology, data transfer can be unidirectional as well as bidirectional. The connection can be established via a cable or wirelessly.
Since it only consists of a receiver and a sender, it is in an advantageous position in terms of data security.
To summarize point-to-point topology;

Advantages:

It has high bandwidth.
Since a connection is established between only two devices, it is quite fast and secure.
It is easy to install and maintain.

Disadvantages:

Since there is a single connection between the devices, the network collapses if this connection is damaged.
Again, since it is a connection consisting of only two devices, the network becomes unusable if either of the two devices breaks down.

Tree Topology

It is basically a topology formed as a combination of star and bus topologies. It is created by gathering branches created in a star shape on a backbone.
In another aspect, tree topology shows similarity to extended star topology. The difference between them is that no central node is needed in tree topology.
Tree topology is used to form the backbone of large networks.
It can be created in two different structures: backbone tree and binary tree. In the backbone tree layout, all nodes are divided into sub-branches in a hierarchical order. In the binary tree layout, each node forms the structure by dividing into only two branches. In tree topology, the flow of data is in a hierarchical order. Therefore, this topology is also called Hierarchical Tree Topology.
To summarize tree topology;

Advantages:

A failure in the connection between sub-devices does not affect the network in general.
Error detection is easy.
Products from different hardware manufacturers can work in harmony.

Disadvantages:

Depending on the type of cable used, the distance between sub-devices may be limited.
A failure in the main backbone causes the entire network to collapse.
In case of excessive traffic on the main backbone, collisions and delays may occur.

Summary

Network topology is the structure that determines how devices in a computer network are connected and how the data transmission process works. While logical topology shows how data flows within the network, physical topology defines how devices are physically connected.
One of the most common physical topologies is the star topology; here, all devices are connected to a central point, making it easy to manage, but if there is a problem at the center, the entire network is affected. Bus topology provides communication over a single line, but performance decreases as the number of devices increases. In ring topology, data circulates through devices in order; this structure prevents collisions, but if a device fails, the entire network may be disrupted. Mesh topology is a secure but costly structure where every device is connected to the others. Point-to-point topology provides the simplest connection but only works between two devices. Tree topology, on the other hand, is used for large networks and ensures that data is transmitted in a hierarchical order.
In conclusion, each topology has its own unique advantages and disadvantages. By choosing the most appropriate structure according to the area of use, the performance and reliability of the network can be ensured.

From Material Planning to Intelligent Systems: The Evolution of ERP

Thu, 15 Jan 2026 00:00:00 GMT

The Industrial Revolution was not an event that happened overnight, nor was it something people adapted to instantly. Just as societies evolve and transform over many years, businesses have also changed and developed over time in line with advancing technology and shifting human needs. Before the 1750s, products were manufactured by hand in workshop-style operations. With the introduction of steam power into production, these workshops gradually evolved into large factories. As time passed, steam power was replaced by electricity. Production became far more efficient, enabling mass manufacturing at an unprecedented scale.

While all these developments were taking place and production volumes were increasing, the process was far from flawless. Production lines came to a halt due to missing raw materials; excess products were manufactured despite existing inventory in warehouses; invoices could not be found even though sales had already taken place. All of these were part of that era. The core issue was no longer merely producing more or producing cheaply. The real challenge had become tracking what was produced and gaining visibility into the business itself.

The first steps taken in the 1960s emerged as a systematic response to this growing need for control within enterprises. Over time, these approaches expanded to cover areas such as production planning, inventory tracking, and finance, forming the foundation of what we now refer to as Enterprise Resource Planning (ERP) systems.

Material Requirements Planning Systems

By the 1960s, businesses were finally able to see what they had in their warehouses. Through inventory tracking software, quantities of raw materials and finished goods were recorded, and attempts were made to forecast the future based on historical data. However, this level of visibility was not always sufficient to effectively manage production.

Knowing what was in stock did not mean knowing when to produce or what would be missing. Increasing production volumes and diversified customer demands confronted managers with far more complex questions. At this point, simple inventory tracking began to fall short as a decision-making tool.

Material Requirements Planning (MRP) systems, introduced in the 1970s, were designed to address exactly this need. MRP systems evaluated orders, existing inventory, and production components together, enabling managers to plan the entire production process. Decision-making processes began, for the first time, to rely not solely on intuition but on systematic data.

However, MRP systems were not flawless under all conditions. Designed primarily for mass production environments, they failed to deliver the same level of success for smaller and more flexible businesses. In markets where demand changed rapidly, these systems were criticized for being unresponsive and struggling to adapt.

These limitations did not lead to the abandonment of MRP, but rather to its expansion. In the 1980s, MRP II systems emerged, extending the original MRP structure with additional functions such as capacity planning, purchasing, and shop floor control, offering a more comprehensive approach to production planning.

The additional functions introduced with MRP II, which were not present in MRP systems, can be listed as follows:

Purchasing function
Shop floor control function
Capacity planning function

ERP Systems

By the 1990s, production in factories was being planned and inventory in company warehouses was being tracked. However, significant gaps still remained. Production and inventory were managed from a single point, but accounting records were kept in separate files, recruitment and other personnel processes were handled in different systems, and the sales department responded to customer requests without real-time awareness of the factory’s situation. In other words, businesses still relied on disconnected data silos, and establishing links between these systems was becoming increasingly complex.

With the concept of Enterprise Resource Planning, introduced into the literature by Gartner Group in the early 1990s, the goal became to connect these independent systems within organizations. In this context, ERP systems expanded beyond MRP II by incorporating modules such as finance, human resources, sales and marketing, quality management, and customer relationship management.

At the heart of this transformation brought by ERP systems was a centralized database. When the sales team entered an order, the production team could see it instantly, and the accounting team could simultaneously generate the necessary invoice. Information became fully accessible from every point within the organization.

Cloud Computing and Artificial Intelligence

Traditional ERP systems are still widely used today. However, this does not mean that technological development has come to a halt. New needs continue to give rise to new features. While traditional ERP systems were highly useful and valuable for businesses, their installation and operational costs often made them risky investments. A problem occurring in the central database could potentially bring the entire organization to a standstill.

With the advancement of mobile technologies and the widespread adoption of the internet, the emergence of cloud computing has driven another evolution in ERP systems. Installation and maintenance costs, which once represented a significant burden for businesses, have largely been eliminated. Instead of building and maintaining an in-house database and system, organizations can now subscribe to ERP services provided by specialized vendors and integrate these systems into their operations quickly and at a relatively lower cost.

Furthermore, the shift to remote working during the pandemic has further increased the importance of cloud computing, making access to data from anywhere with an internet connection a critical requirement.

Another stage in the evolution of ERP systems is the integration of artificial intelligence, now an indispensable part of modern technology. With AI, businesses no longer merely record data; they can also use that data to generate consistent and actionable insights for future decision-making.

Conclusion

With the Industrial Revolution, businesses seeking to accelerate production gradually began to feel the need not only to produce more, but also to understand and control production. At the point reached today, the issue is no longer merely about producing or recording data; it is about deriving meaning from data and making the right decision at the right time. The historical journey of ERP systems represents a summary of the technological responses developed to meet this ongoing pursuit of businesses.

Minimum Product, Maximum Clarity: The Importance of Requirements Analysis in MVP

Wed, 31 Dec 2025 00:00:00 GMT

As we wrap up 2025, I wanted to share a final piece reflecting on my journey in Business Analysis and MIS. This year has been about growth, and what better way to close it than discussing the intersection of MVP and clarity? Thank you for being part of my journey this year. See you in 2026, with more insights, experiments, and reflections on building meaningful products. (P.S. If the calendar flipped before you got here, consider this a tiny MVP: a minimal yet meaningful wish for your 2026!)

MVP (Minimum Viable Product) is an approach that aims to deliver a product to users at the earliest possible stage with minimum effort and minimum features. The core objective is not to make the product perfect, but to test whether it is on the right track by collecting early user feedback.

In practice, however, MVP is often reduced to the idea of a “first working version.” This leads to projects being released under the name of MVP despite not offering a clear solution to any specific problem.

The real value of an MVP lies in whether it genuinely addresses a problem and produces a solution. If the product does not serve a clear purpose—or in other words, does not solve a real problem—the feedback collected from users will inevitably be weak or misleading. In such cases, the development team will struggle to interpret feedback correctly, increasing the risk of future product iterations drifting away from actual market needs.

For this reason, it is more accurate to think of an MVP not merely as a minimum-featured first release, but as a minimum product that delivers a solution. So what is the key element that transforms an MVP from an unfinished product into a problem-solving one? This is where requirements definition and requirements analysis come into play.

What Is Requirements Analysis?

Requirements analysis is the process of examining, evaluating, and documenting the requirements identified during the requirements elicitation phase. When broken down conceptually, the idea becomes clearer: a requirement represents a desired feature or capability of a product, while analysis refers to evaluating and documenting these features. In product development, requirements analysis plays a critical role in understanding stakeholder needs.

The main objectives of requirements analysis include:

First and foremost, understanding users’ needs and expectations.
Since requirements are often gathered from multiple sources, inconsistencies and conflicts may arise. Requirements analysis helps identify and resolve these contradictions.
User feedback may result in numerous requirements. Requirements analysis enables these to be prioritized.
Requirements may need to be grouped and structured under different categories. Requirements analysis supports proper classification and organization.

The Relationship Between MVP and Requirements Analysis

At first glance, MVP and requirements analysis may appear to be unrelated—or even contradictory—concepts. MVP focuses on minimum effort and minimum functionality, while requirements analysis may seem to expand scope. In reality, the opposite is true.

Requirements analysis allows an MVP to focus on a single, well-defined point. Which features are most demanded by users? Which features are desirable but not critical for the MVP? Why do users want to use the product? What problems does the product aim to solve? Answers to these questions can only be identified through a well-executed requirements analysis, enabling the MVP to align closely with real market needs.

Why Does an MVP That Doesn’t Solve a Problem Fail to Generate Feedback?

Let’s consider a simple example. Imagine releasing an MVP of a personal finance application designed to simplify expense tracking. The first version only allows users to add income and expenses. However, because the actual needs of the target audience were not thoroughly analyzed, users do not find the application any different from existing alternatives. As a result, the team receives either vague or directionless feedback. Without a clearly defined problem, user feedback becomes insufficient to drive meaningful product improvement.

At the root of this issue is often not technical inadequacy, but poorly defined requirements at the beginning of the product development process. If the target problem and user segment are not clearly identified during the MVP phase, the feedback collected will naturally be scattered and unfocused. Had requirements analysis been conducted properly from the start, it would have been clearer which features should be included in the MVP—and which should not.

Let’s examine the example in more detail:

What users want: Detailed reporting, automatic categorization, regular import/export options.
What the MVP offers: Income entry / Expense entry.
The actual problem users face: Existing personal finance applications on the market lack the detailed reporting features mentioned above.
Does the MVP solve this problem? No. Because requirements analysis was not performed, the team did not fully understand user needs. As a result, yet another undifferentiated personal finance application was released.
What should have happened: A requirements analysis conducted before the MVP phase should have identified user needs and priorities. The MVP should then have been designed based on these findings, delivering a solution that genuinely addresses the user’s problem. This would have led to more focused feedback, making it easier to define future iterations and the product roadmap.

Conclusion

The success of an MVP is not measured by how few features it has, but by which problem it solves. MVPs developed without requirements analysis tend to miss real user needs, resulting in vague and unfocused feedback. The outcome for the development team is uncertainty.

Rather than viewing requirements analysis as a time-consuming activity that broadens scope, it should be seen as a guiding tool that defines the right direction for MVP focus.

Browser or Product Showcase? How Mozilla Lost Its Way

Wed, 24 Dec 2025 00:00:00 GMT

Let’s be honest: The slow decline of Firefox isn’t because of a technical glitch. It’s a full-blown identity crisis.

Once upon a time, Firefox stood as the champion for “the people’s internet.” Today? It’s starting to feel less like a browser and more like a high-tech showroom for VPNs, AI chatbots, and endless subscription pitches. This shift isn’t just a tweak in product strategy; it’s a total fracture in the trust between Mozilla and its users.

In this analysis, I want to look beyond the usual “why is Firefox losing market share?” questions. I want to dig into how Mozilla Corporation actually lost its way—examining their revenue dependency, the messy PPA decisions, executive incentives, and a confused AI strategy. This isn’t just the story of a browser in trouble; it’s a deep dive into the identity crisis of a tech icon. The Engine Monopoly: A World Painted Chrome

When we talk about browsers today, we’re really talking about two different worlds: those powered by the Blink engine and those standing on Gecko. Sure, Apple has WebKit, but the real mainstream battle happens between these two.

On one side, you have the Blink empire—Chrome, Brave, Opera, Vivaldi, and Edge—which basically owns the market. On the other side, you have the lone survivor, the Gecko engine, with Mozilla Firefox at its helm, watching its market share slip away year after year.

{{< chart >}} type: ‘bar’, data: { labels: [‘Chrome’, ‘Safari’, ‘Edge’, ‘Firefox’, ‘Samsung Internet’, ‘Opera’, ‘Diğerleri’], datasets: [{ label: ‘2025 Browser Market Share (%)’, data: [68.51, 16.35, 5.01, 2.42, 2.08, 1.95, 1.57], backgroundColor: [‘#4285F4’, ‘#34A853’, ‘#FBBC05’, ‘#EA4335’] }] } {{< /chart >}}

To understand why this decline feels so personal to many of us, you have to remember where Firefox came from. It wasn’t born in a corporate boardroom; it was born in a revolution. Firefox was the “Phoenix” (its original name) that rose from the wreckage of Netscape after the first Great Browser War.

Back in 2004, when Internet Explorer had a 95% stranglehold on the web, Firefox 1.0 was our declaration of independence. It was fast, it was ours, and it was built by a community that actually cared. A year later, the Mozilla Foundation was born, positioning Firefox as more than just code—it was the guardian of openness, privacy, and user rights.

{{< chart >}} type: ‘line’, data: { labels: [ ‘2000/Q1’, ‘2000/Q2’, ‘2000/Q3’, ‘2000/Q4’, ‘2001/Q1’, ‘2001/Q2’, ‘2001/Q3’, ‘2001/Q4’, ‘2002/Q1’, ‘2002/Q2’, ‘2002/Q3’, ‘2002/Q4’, ‘2003/Q1’, ‘2003/Q2’, ‘2003/Q3’, ‘2003/Q4’, ‘2004/Q1’, ‘2004/Q2’, ‘2004/Q3’, ‘2004/Q4’, ‘2005/Q1’, ‘2005/Q2’, ‘2005/Q3’, ‘2005/Q4’, ‘2006/Q1’, ‘2006/Q2’, ‘2006/Q3’, ‘2006/Q4’, ‘2007/Q1’, ‘2007/Q2’, ‘2007/Q3’, ‘2007/Q4’, ‘2008/Q1’, ‘2008/Q2’, ‘2008/Q3’, ‘2008/Q4’, ‘2009/Q1’, ‘2009/Q2’, ‘2009/Q3’, ‘2009/Q4’ ], datasets: [ { label: ‘Netscape’, data: [19.53, 15.97, 13.27, 11.67, 10.61, 9.13, 7.20, 6.16, 5.10, 4.56, 3.91, 2.92, 2.24, 1.74, 1.41, 0.97, 0.69, 0.35, 0.15, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], fill: false, // Alanı doldurma borderColor: ‘rgb(95, 182, 193)’, // Turkuaz tension: 0.3 }, { label: ‘Internet Explorer’, data: [77.77, 79.49, 81.12, 83.16, 85.20, 87.38, 87.25, 89.51, 91.20, 92.41, 92.64, 93.42, 93.97, 94.21, 94.46, 94.68, 94.49, 94.30, 95.04, 92.70, 90.98, 90.78, 90.89, 87.92, 87.29, 89.55, 86.94, 84.79, 84.17, 83.77, 83.11, 81.94, 81.27, 79.50, 78.47, 77.00, 73.11, 67.55, 63.73, 61.09], fill: false, // Alanı doldurma borderColor: ‘rgb(68, 114, 196)’, // Mavi tension: 0.3 }, { label: ‘Firefox’, data: [0, 0, 0, 0, 0, 0, 0, 0, 0.76, 0.97, 1.18, 1.41, 1.73, 2.16, 2.25, 2.51, 2.60, 2.69, 2.37, 2.66, 4.06, 4.92, 6.63, 7.74, 8.09, 8.76, 8.98, 9.79, 10.82, 12.60, 15.40, 19.45, 22.62, 25.08, 26.03, 26.05, 26.63, 27.02, 28.13, 29.86], fill: false, // Alanı doldurma borderColor: ‘rgb(237, 125, 49)’, // Turuncu tension: 0.3 } ] }, options: { elements: { point: { radius: 0 } }, scales: { y: { // stacked: true, beginAtZero: true, max: 100, title: { display: true, text: ‘Market Share (%)’ } }, x: { ticks: { autoSkip: true, maxTicksLimit: 10 }, grid: { display: false } } }, plugins: { legend: { position: ‘right’ } } } {{< /chart >}}

But here is where it gets complicated. In 2005, the establishment of the Mozilla Corporation created a permanent, gnawing tension between a public mission and the cold reality of commercial survival. The crisis we see today is the direct result of that friction.

The Manifesto vs. The Corporation

On August 3, 2005, the non-profit Mozilla Foundation created a taxable subsidiary: the Mozilla Corporation. The idea was simple on paper: the Corporation would handle development and marketing to serve the Foundation’s noble goals. They launched with powerful slogans like “Internet, By The People, For The People,” and a manifesto that felt like a digital Bill of Rights:

The internet is a global public resource that must remain open and accessible.
The internet must enrich the lives of individual human beings.
Security and privacy are fundamental and cannot be treated as optional.
Transparent, community-based processes are the only way to build trust.
Commercial involvement is fine, but the balance between profit and public good is critical.

Fast forward to today, and the evidence is mounting that the “balance” has tipped. The center of gravity has shifted away from the public mission and toward the Corporation’s desperate commercial needs.

The Golden Handcuffs: The Google Problem

Let’s talk about the elephant in the room: Mozilla’s bank account is basically a Google paycheck. With the US Department of Justice (DOJ) breathing down Google’s neck over search monopolies, Mozilla’s primary source of income is on life support. If those payments stop, Mozilla’s current model collapses.

This financial panic is exactly what’s driving leadership toward “revenue diversification.” This is the real story behind PPA (Privacy Preserving Attribution). It’s their attempt to play ball with the ad industry without looking like the “bad guys.” But for a community that uses Firefox specifically to escape the ad-tech nightmare, this pivot felt like a betrayal.

Development ‘Against’ the User: The PPA Decision

To understand the backlash, we have to look at what PPA actually does. In traditional advertising, you’re tracked across the web by third-party cookies—it’s digital surveillance, plain and simple. Mozilla claims PPA fixes this by moving that “tracking” logic into the browser itself.

The system works like this:

Local Logging: Your interactions are stored locally on your device.
Client-Side Matching: The “match” happens inside your browser; no personal data leaves the machine.
DAP Protocol: Results are encrypted using the Distributed Aggregation Protocol (DAP).
Noise: Random “noise” is added to anonymize the data before it ever hits an advertiser’s server.

On paper, it looks like a clever technical compromise. But the crisis wasn’t about the code; it was about consent. Mozilla pushed PPA in Firefox 128 as enabled by default (opt-out) instead of asking users to join (opt-in). For a brand that preaches “user agency,” this was a massive blow to the social contract. They risked their users’ trust just to build a large enough data pool for advertisers. The result? A loss of prestige that might be impossible to repair.

Rewarding Failure: The Incentive Paradox

In any normal tech company, if your market share drops below 3%, the leadership takes the hit. At Mozilla? It’s been the exact opposite. While Firefox bled users, executive compensation packages stayed massive.

During the layoffs of 2020 and 2024, the “cost-cutting” didn’t hit the suits; it hit the engineers—the people actually building the engine. When you reward management for a shrinking product, you don’t get innovation; you get desperation. That’s why we see decisions like PPA.

{{< chart >}} type: ‘line’, data: { labels: [‘2009’, ‘2010’, ‘2011’, ‘2012’, ‘2013’, ‘2014’, ‘2015’, ‘2016’, ‘2017’, ‘2018’, ‘2019’], datasets: [ { label: ‘Chair Pay (Million $)’, data: [0.5, 0.58, 0.57, 0.71, 0.8, 1.03, 1.02, 1.11, 2.35, 2.48, null], borderColor: ‘rgba(175, 26, 26, 1)’, // Kırmızı backgroundColor: ‘rgba(255, 0, 0, 0.1)’, yAxisID: ‘y_pay’, // Sol eksene bağla tension: 0.1 }, { label: ‘Firefox Usage (%)’, data: [30.2, 30.4, 26.5, 21.2, 16.5, 13.1, 10.4, 8.0, 6.2, 5.2, 4.5], borderColor: ‘rgba(31, 31, 175, 1)’, // Mavi backgroundColor: ‘rgba(0, 0, 255, 0.1)’, yAxisID: ‘y_usage’, // Sağ eksene bağla tension: 0.1 } ] }, options: { responsive: true, scales: { y_pay: { type: ‘linear’, display: true, position: ‘left’, title: { display: true, text: ‘Chair Pay (Million $)’ }, min: 0, max: 3, ticks: { callback: function(value) { return ’$’ + value + ‘m’; } } }, y_usage: { type: ‘linear’, display: true, position: ‘right’, title: { display: true, text: ‘Market Share (%)’ }, min: 0, max: 35, grid: { drawOnChartArea: false }, // Sağ eksenin çizgileri solla karışmasın ticks: { callback: function(value) { return value + ’%’; } } } } } {{< /chart >}}

From Browser to Product Portfolio: VPN, Relay, and More

Mozilla’s scramble to reduce its Google dependency has led to an “ecosystem of subscriptions.” We now have Mozilla VPN, Firefox Relay, and Monitor. While a privacy brand selling privacy tools makes sense, it has caused a massive split in resources.

The community’s feedback has been loud and clear: “We don’t want the world’s best VPN from you; we want a browser that doesn’t get crushed by Chrome.” But Mozilla is increasingly treating the browser not as the core product, but as a distribution channel for these secondary services.

Mozilla’s New Compass: The AI Dilemma

Every new tech “hype” now seems to find its way into the Firefox roadmap. After controversial experiments with Web3 and Crypto, Mozilla has pivoted hard to “Trustworthy AI.” They are stuffing the browser with chatbots and “AI Assistants.”

But there’s a massive doctrinal contradiction here. AI models need data—and lots of it. Firefox’s whole reason for existing is data minimization and privacy. Chasing Silicon Valley trends instead of listening to their own core community suggests a corporation that has truly lost its North Star.

Conclusion: The Solitude of Gecko

The story of Firefox is ultimately the answer to one question: “Who is the internet for?” Today, Chromium-based browsers control over 90% of the market. We are living in a monoculture where Google effectively dictates web standards. Gecko is the last fortress protecting digital biodiversity.

If Mozilla cannot return to the radical transparency and user-centricity of its founding manifesto, Firefox faces the same fate as Netscape.

Mozilla doesn’t need to ship a flashy new feature today. It needs to sit down and re-declare what it will never do. Firefox isn’t just an “option”; for many of us, it’s a stance. It’s time Mozilla started acting like it.

How to Install Cisco Packet Tracer on Linux Using Distrobox

Mon, 21 Apr 2025 00:00:00 GMT

Every student or professional stepping into the world of networking eventually crosses paths with Cisco Packet Tracer. However, if you are a Linux enthusiast who prefers a distribution not based on Debian/Ubuntu (like Fedora, Arch, OpenSuse etc.), a slightly unpleasant surprise awaits you on Cisco’s download page: Only a .deb package is available. The absence of an official version in stores like Snap or Flatpak usually forces users into two inconvenient options: Setting up a Virtual Machine (VM) and straining system resources. Switching distributions just for this single application.

However, there is a third and much more efficient way: Distrobox. In this guide, I will explain how to run Packet Tracer like a native application without chancing your Linux distribution or dealing with heavy virtual machines.

What is Distrobox?

I won’t go into a lengthy explanation of the architecture here, but briefly: Distrobox is a tool that allows you to run any Linux distribution of your choice inside your current terminal using containerization tools like Docker or Podman. For more detailed information, you can visit the official Distrobox website. Installing Distrobox You can install Distrobox using your distribution’s package manager, just like any other software.

OpenSUSE:

sudo zypper install distrobox

Solus:

sudo eopkg install distrobox

Fedora:

sudo dnf install distrobox

For other distributions, you can install it similarly using your package manager. Note: If Podman or Docker was not installed automatically during the Distrobox installation, you need to install one of them. I will proceed using Podman in this guide.

Installing Packet Tracer We have completed the Distrobox and Podman installations. Now , it’s time to create the environment where we can install .deb packages. Open your terminal and run the following commands in order: Create a Debian environment using Distrobox: (I used the $USER variable here so it works automatically for your username)

distrobox-create --name Debian --image debian:12 --home /home/$USER/distrobox/debian12
Enter the Debian environment:

distrobox-enter Debian
Update the environment:

sudo apt update
Install the necessary dependencies:

sudo apt install libqt5multimedia5 libqt5xml5 libqt5script5 libqt5scripttools5 libqt5sql5

Now comes the easiest part. You need to go to Cisco’s website and download Packet Tracer. Make sure to select the Ubuntu version. Once the download is complete, return to the terminal (ensure you are still inside the Distrobox container)

cd ~/Downloads
# Or navigate to wherever you saved the file.
Install the downloaded file:
sudo apt install ./CiscoPacketTracer...
# Tip: Type 'sudo apt install ./Cisco' and hit Tab to auto-complete the filename.

Congratulations! Technically, the installation is complete. However, right now, you would need to enter the Debian container via the terminal to launch Packet Tracer. To avoid this and make it accessible like a regular app, there is one final step. Run this command in the terminal (inside the container):

distrobox-export -app packettracer

That’s it! You can now access and run Cisco Packet Tracer directly from your system’s application menu. You can close the terminal now.

kuscadev | Minimal. Practical. Worth Sharing.

What is Network Topology?

What is Network Topology?

What is Logical Topology?

What is Physical Topology?

Bus Topology

Advantages:

Disadvantages:

Ring Topology

Advantages:

Disadvantages:

Star Topology

Advantages:

Disadvantages:

Mesh Topology

Advantages:

Disadvantages:

Point-to-Point Topology

Advantages:

Disadvantages:

Tree Topology

Advantages:

Disadvantages:

Summary

From Material Planning to Intelligent Systems: The Evolution of ERP

Material Requirements Planning Systems

ERP Systems

Cloud Computing and Artificial Intelligence

Conclusion

Minimum Product, Maximum Clarity: The Importance of Requirements Analysis in MVP

What Is Requirements Analysis?

The Relationship Between MVP and Requirements Analysis

Why Does an MVP That Doesn’t Solve a Problem Fail to Generate Feedback?

Conclusion

Browser or Product Showcase? How Mozilla Lost Its Way

The Manifesto vs. The Corporation

The Golden Handcuffs: The Google Problem

Development ‘Against’ the User: The PPA Decision

Rewarding Failure: The Incentive Paradox

From Browser to Product Portfolio: VPN, Relay, and More

Mozilla’s New Compass: The AI Dilemma

Conclusion: The Solitude of Gecko

How to Install Cisco Packet Tracer on Linux Using Distrobox

What is Distrobox?

Accessing Packet Tracer from the Application Menu