35 Comments

1. 2025-09-15 11:50 am

   kurkosdr

   This is what I “love” (i.e. hate) about Desktop Linux:

   – Can’t decide which binaries are core and non-core? Eliminate the separation and put them all in /usr

   – Can’t agree to put the non-root binaries in bin and the root binaries in sbin? Eliminate the separation and put everything in bin.

   And while I am willing to give them the benefit of the doubt for the first one (deciding what is “core” and “non-core” can be tough), the second one is just idiotic. A tool either needs root to work at all or it doesn’t.

   This is what you get when you have too many neckbeards and graybeards with opinions™ spread across multiple organizations/distros and no boss to enforce a single decision.
• 2025-09-15 5:06 pm

  markr

  > A tool either needs root to work at all or it doesn’t.

  That’s not always true, though. Docker requires root in its default configuration – but that can be changed so that non-root users can run docker without sudo.
• 2025-09-15 6:01 pm

  Alfmanverbose=1

  That’s not always true, though. Docker requires root in its default configuration – but that can be changed so that non-root users can run docker without sudo.

  I was going to say this too, I don’t think “root” designation is particularly logical. Some admin tools like “ip” will still output useful data in readonly mode even though some functionality obviously won’t work without root.

  The partition manager “parted” (which is in sbin on debian) can and should be used bynormal users working with disk images (ie virtual machine disk image files). It’s not the tool itself that determines whether root access is needed, but the file or block device that gets passed in. This is the case for other tools in sbin too. Therefor dividing programs between “bin” and “sbin” based on “root” is not that useful IMHO.

  My own distro symlinks /bin to /sbin and that’s just as good.

  A tangential point: I dislike the unix practice of stuffing thousands of binaries into global directories. Its bad for organization. It might have made sense at first when there just wasn’t that much software,, but it set a bad precedent for the future. Software files should be kept together in local directories. Gobolinux handles this better or (dare I say it…) even windows “program files”.

  While I don’t condone many of microsoft’s ugly hacks (like program files 86), the basic idea that software be organized within their own directory structures is a good one. I like the idea of installation & uninstallation be contained to a directory without spaying resources across the file system into system-wide garbage heaps.
• 2025-09-19 3:22 am

  emarsk

  Gobolinux! I forgot about that. I gave it a try years ago but it had issues. Is it still going?
• 2025-09-15 6:03 pm

  kurkosdr

  Some programs require sudo no matter what (under standard file permissions), for example dpkg. Only those go to sbin. How did the Unix graybeards and Linux neckbeards manage to complicate something so simple is beyond me. This is what you get when you have people with opinions™ (with each person trying to drag things to their own point of view) and with no boss to say “only binaries that require sudo no matter what under standard file permissions go to sbin, the rest goes to bin, period”.
• 2025-09-15 10:07 pm

  Alfmanverbose=1

  kurkosdr,

  Some programs require sudo no matter what (under standard file permissions), for example dpkg. Only those go to sbin. How did the Unix graybeards and Linux neckbeards manage to complicate something so simple is beyond me. This is what you get when you have people with opinions™ (with each person trying to drag things to their own point of view) and with no boss to say “only binaries that require sudo no matter what under standard file permissions go to sbin, the rest goes to bin, period”.

  Not for nothing but even your example requires a non-universal judgement call. Dpkgcan be used by non-root users and there’s nothing even weird about it. You can use it with a local install path, or even just to view and extract package files. You might want to do on shared hosting where you don’t have root for instance.

  On the one hand it doesn’t really matter if it goes in bin or sbin because non-root users can call binaries in sbin anyway. But based on your own rule, I can’t make sense of placing dpkg into sbin. A dev might use it to build deb files without root/sudo and I expect some do. Even a utility like mkfs.ext4, which has “root” written all over it, lets ordinary users create file system images. Obviously I know it has applications for root users, but we cannot claim that it can’t be used by non-root users.

  I don’t really see the point in sbin at all. Your simple/obvious rules are subjective and lead to inconsistent interpretations anyway, Why does it matter at all? It just seems like a pointless subjective endeavor to determine whether a binary belongs in bin or sbin because whether we get it right or wrong there’s not much benefit for having done it.
• 2025-09-18 7:47 pm

  ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!)

  *nod* I’ve used `dpkg -S $(which cmdname)` or `dpkg -L pkgname` at least 20 times as much as I’ve used the side of it requiring sudo.

  (-S tells you which package provides a path and -L lists the paths provided by a package. The former is useful for packages which provide multiple commands with no obvious connection to their package name, and the latter is useful for things like “What the heck did this package name its binary?” or “Where are the system config files?”)
• 2025-09-16 4:31 am

  rastersoft

  I constantly use `dpkg -L XXXX` to list the files contained in a package. Or `dpkg -S /aaa/bbb/ccc` to find which package installed the file `/aaa/bbb/ccc`. And neither need sudo.
• 2025-09-20 4:39 am

  darkhog

  It’s important to remember that /usr directory itself is used “wrongly”. Originally it was supposed to serve the same purpose /home serves now, i.e. store users’ personal files, with binaries going to either /bin or /sbin (or /lib if we’re talking libraries).
2. 2025-09-15 12:26 pm

   rene

   I like sbin, and in T2/Linux we even still maintain the split of system core things in / and non vital things in /usr. If I were to remove and join anything that it would be getting rid of /usr entirely. and only use /bin,/sbin, …
• 2025-09-16 9:22 pm

  Flatland_Spider

  I agree with this.

  Ideally “/usr” would be everything not in the core OS. “/usr” would be for user installed extras, and “/usr/local” would be for stuff locally compiled or 3rd party like it should be (basically what “/opt” is used for). 🙂

  I would still get rid of “/sbin” though. 🙂 Most interactive systems are single seat, so it’s not the best distinction.
3. 2025-09-15 1:29 pm

   ponk

   Short answer — /usr/sbin (and /usr/local/sbin) should be where to place commands that require you to “sudo”.
• 2025-09-16 9:16 pm

  Flatland_Spider

  That would make sense. I’m not sure anything in “/usr/local” should need privilege elevation, but that’s a different conversation.
4. 2025-09-15 10:03 pm

   sukru

   It used to be /bin for binaries, and /usr for “user directories”.

   /bin (and /sbin) were local, and /usr was mounted over NFS.

   Over time software started installing themselves in /usr, and they were large and needed to be shared across labs or even campus.

   That slowly pushed users’ home directories … to /home (and /usr became “Unix System Resources”)

   And now we are stuck with that decades later. There is no more NFS for most builds. Local HDDs are large enough to store all software we need, even for tiny devices like Raspberry Pi. And we don’t even need it during boot (there used to be a concern for /usr not being mounted), as we have a “disposable” ram disk during boot process for this anyway.

   A “good” desktop Linux could easily do away with /usr and just have /bin, /sbin, (and /lib). And /local? can go into /opt (ah, yes, I completely forgot about it. /opt is where third party place themselves outside of the packaging system. things like “mamba” where they manage their own setups).

   @Thom, please enablett and/orpre tags on the site.
• 2025-09-22 10:53 am

  Parodper

  A “good” desktop Linux could easily do away with /usr and just have /bin, /sbin, (and /lib).

  Then you can’t have all the system static files in a separate partition, so mounting a remote /usr or immutable systems are out.
5. 2025-09-16 4:27 am

   bert64

   I always liked the separation of function, and it made sense for system management tools like fsck to be in sbin and userland binaries like the shell to be in bin. Lumping everything together just feels a step towards the “dump everything in system32” approach taken by windows, which always looked extremely messy.
• 2025-09-16 8:36 am

  Alfmanverbose=1

  bert64,

  I always liked the separation of function, and it made sense for system management tools like fsck to be in sbin and userland binaries like the shell to be in bin. Lumping everything together just feels a step towards the “dump everything in system32” approach taken by windows, which always looked extremely messy.

  Lumping everything together is extremely messy (as is system32).. It’s just a poor organizational fix for that mess because both bin and sbin feel like a system32 garbage pile even though you have two of them. I liked that gobolinux are trying something different. My vote would be for mainstream distros to clean it up too with a deep reorganization, but I realize that changing established precedent is really hard regardless of the merits.
6. 2025-09-16 10:19 am

   Iapx432

   To further confuse newbies, you must use sudo to install files into /usr/bin. As a result, many package managers install binaries into the user’s home directory, typically under ~/.local/bin, so they are not available to other users.
• 2025-09-16 7:12 pm

  Alfmanverbose=1

  Iapx432,

  To further confuse newbies, you must use sudo to install files into /usr/bin. As a result, many package managers install binaries into the user’s home directory, typically under ~/.local/bin, so they are not available to other users.

  It’s just awfully inefficient to have software that installs itself under ~/.local or similar. Games in particular can use many gigabytes and you don’t want every user to install their own copy. I keep wondering if there’s a more elegant way to solve thiswithout requiring users have root access.

  Perhaps a file system can dedup identical files across user accounts. But even if that works I still don’t think it’s great that every user needs to install/update the software within their user directory.

  It seems like the OS could have a new type of trust domain whereby the software itself get get it’s own special user account in which the software is installed & updated using signatures validated though HTTPS. Multiple users trying to run the same software would be able to use the already installed copy. And thanks to the HTTPS validation would know other (non-root) users haven’t tampered with it. Users would have the ability to run these programs from their own accounts normally. For the sake of security, the software should be sandboxed from accessing/interfering with the user’s files. unless specifically allowed.

  I don’t think I’ve ever seen a multiuser OS that works this way. It’s an off the cuff idea, but it could be an interesting alternative to the problem of requiring root or having users installing copies under their profile.
• 2025-09-16 9:35 pm

  Flatland_Spider

  I keep wondering if there’s a more elegant way to solve this without requiring users have root access.

  In the past I’ve solved this by giving the “users” group ownership of “/usr/local” and setting the sticky bit.

  There is also sudo magic which could work to limit the scope of the command. This would require setting the target group and command, I think. I’d have to try this to be 100%.

  .Perhaps a file system can dedup identical files across user accounts. But even if that works I still don’t think it’s great that every user needs to install/update the software within their user directory.

  CoW filesystems can do this, and it’s supposed to be one of the star features. However, it doesn’t work that well, and it breaks encryption.

  I’m perfectly fine with people installing software into their homedir. I’d rather they do that then installing it on the system. I’m also amazed package managers don’t allow this by default. “dnf –user install tmux” should install tmux into my homedir.

  It seems like the OS could have a new type of trust domain whereby the software itself get get it’s own special user account in which the software is installed & updated using signatures validated though HTTPS. Multiple users trying to run the same software would be able to use the already installed copy. And thanks to the HTTPS validation would know other (non-root) users haven’t tampered with it. Users would have the ability to run these programs from their own accounts normally. For the sake of security, the software should be sandboxed from accessing/interfering with the user’s files. unless specifically allowed.

  Are you quoting the flatpak docs?
• 2025-09-16 11:05 pm

  Alfmanverbose=1

  Flatland_Spider,

  In the past I’ve solved this by giving the “users” group ownership of “/usr/local” and setting the sticky bit.

  There is also sudo magic which could work to limit the scope of the command. This would require setting the target group and command, I think. I’d have to try this to be 100%.

  Yeah, I am trying to think of a way for it to work between untrusted users though. Not that the goal is to have malicious users on the system, but as a matter of principal users should be able to efficiently install the same software without trusting each other.

  For such a setup to work effectively and be secure, I think the following requirements would need to be met:
  1) There needs to be a shared software collection that all the users can publish to

  2) Each title published into the software collection needs to be downloaded/installed/verified from an upstream source such as an RPM, DEB, Flatpak, zip, tar.xz, etc. The OS would perform the extraction and authenticate the local installation is a genuine installation, this fact can be communicated to all the users of the system. Naturally the OS can’t vouch for the what the software does (hence the reason to run it in a sandbox), but the OS should be able to precisely vouch for the URL it was downloaded from. Users who trust that URL should trust the software in the collection.

  3) Users should have a nice tool to browse/install/customize all software from the shared collection into their own profile. This could mean symlinks, COW FS, bind mounts, or whatever. But the user could not change the software collection by themselves.

  4) The system could periodically garbage collect unreferenced software that all users have uninstalled in their profiles.

  It seems like it should work in principal, but I imagine there may be gotchas if I actually tried to implement it. One issue is that a lot of software doesn’t come in a ready to install package format from upstream. This is important for the install to be automated. If the install requires manual intervention, then root could still do it, but that kind of defeats the purpose of the idea, which is to install software without root.

  CoW filesystems can do this, and it’s supposed to be one of the star features. However, it doesn’t work that well, and it breaks encryption.

  I see what you mean about breaking encryption within one file system. This is well outside the scope of anything I had in mind, but for the sake of discussion… I’ve used overlay file systems to overlay readonly squashfs images with tmpfs and it would probably work here too. An overlayfs with COW semantics would let you overlay an encrypted user directory on top of the unencrypted software directory. Then you’d be free to modify the software and have those changes be written into your encrypted profile.

  I’m perfectly fine with people installing software into their homedir. I’d rather they do that then installing it on the system. I’m also amazed package managers don’t allow this by default. “dnf –user install tmux” should install tmux into my homedir.

  The reason I don’t like this is that it really adds up. Say both my kids install the Hogwarts game, which they both play, into their profile, that’s 85GB per install (not to mention I installed it too). Granted, I cherry picked this game because it’s the largest one we have, but it’s not uncommon for titles to be ~5GB, which is still a lot to duplicate. I don’t consider the duplication of such large resources to be reasonable. Some of the LLM’s I’ve been experimenting with are also in the ~70GB range. Even we want to say just buy larger disks to hold everyone’s files including dups, I would argue that linuxshould offer a better solution. Of course I technically have root on my systems, so I can manually accomplish the sharing I need, but I was thinking of ways we might make shared software work better out of the box without root.

  Are you quoting the flatpak docs?

  Haha. I can see similarity in scope. Does flatpak solve the multiuser installation problem? If it does, then I did not know about that and I’d be very interesting in learning more about it!
7. 2025-09-16 6:06 pm

   jgfenix

   I thought that /sbin was for critical system binaries that were statistically linked.
• 2025-09-16 6:47 pm

  Alfmanverbose=1

  jgfenix

  I thought that /sbin was for critical system binaries that were statistically linked.

  I think there’s some truth to that, however keeping static binaries in their own directory was not really a goal in and of itself. It was just a consequence of the very specific technical purpose these directories had: being mount points for different physical disks. Multiple disks were needed due to size constraints. System software located in sbin would need to boot the rest of the system and could not be dependent on libraries on a different disk that have not been mounted yet.

  None of this is true anymore and we’ve long outgrown the need to boot across disks, But rather than reevaluting the directories, we’ve kept them as a convention, with the split becoming more arbitrary over the years. Some people try to retroactively justify their importance, but if not for hardware constraints mandating unix have multiple disk mount points, this division would probably never have come to exist.

  https://lists.busybox.net/pipermail/busybox/2010-December/074114.html

  Of course they made rules about “when the system first boots, it has to come up
  enough to be able to mount the second disk on /usr, so don’t put things like
  the mount command /usr/bin or we’ll have a chicken and egg problem bringing
  the system up.” Fairly straightforward. Also fairly specific to v6 unix of 35
  years ago.

  The /bin vs /usr/bin split (and all the others) is an artifact of this, a
  1970’s implementation detail that got carried forward for decades by
  bureaucrats who never question _why_ they’re doing things. It stopped making
  any sense before Linux was ever invented, for multiple reasons:…
• 2025-09-16 9:08 pm

  sukru

  Alfman,

  One other concern is backwards compatibility.

  I, too, would like a “clean slate”.

  However things like UNIX compatibility, and Linux Standard Base make it extremely difficult to remove them. (At best we would have them symlink to /usr/bin and so on).
• 2025-09-16 11:22 pm

  Alfmanverbose=1

  sukru,

  One other concern is backwards compatibility.

  I, too, would like a “clean slate”.

  I tried in vein in to create a new hierarchy in my linux distro. I still feel that we can do much better. I wanted unzipping to equal installation, and uninstallation to be removing the directory. It’s such a simple & elegant idea. Old school DOS/windows and macos software work this way and frankly it was awesome! I think people are longing for simpler software installation. But the big con with my attempts came down to compatibility. So many packages that I wanted to install needed to be repackaged that it become non-viable for me to maintain and I threw up my arms. Mainstream distros that have more resources to do it aren’t as likely to be innovative here.

  Aside: Now days I wonder if it would be possible to employ an AI agent to automate the necessary changes to modify software packages for the new scheme?
• 2025-09-18 7:56 pm

  ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!)

  For me, the biggest deal-breaker is that doing JUST that (i.e. without also adding something akin to what classic Mac OS does under the hood to maintain the Desktop DB) will not integrate it into $PATH and `man` and file-type associations and the like.

  You need some kind of filesystem-watching daemon to add and remove system integrations.
• 2025-09-18 9:10 pm

  Alfmanverbose=1

  ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!),

  For me, the biggest deal-breaker is that doing JUST that (i.e. without also adding something akin to what classic Mac OS does under the hood to maintain the Desktop DB) will not integrate it into $PATH and `man` and file-type associations and the like.

  You need some kind of filesystem-watching daemon to add and remove system integrations.

  I think that’s a good idea. I don’t think it would be that hard to do. As a side benefit a proper index could be even more efficient than $PATH. $LD_LIBRARY_PATH, etc.

  Ideally the file system & kernel would be able to automatically index files with robust integrity like databases can, but we don’t have this today and it’s probably not likely to change anytime soon.

  Still there’s a lot that can be done just in userspace and we’ve seen it in other contexts like music software that scans mp3 tags. The linux “fnotify” API is useful to monitor changes in the file system without having to be told to rescan the software. This could be very useful to efficiently maintain a software index. This would work for launching software, but also other assets such as man pages, like you said.
• 2025-09-20 4:56 am

  ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!)

  *nod* Classic Mac OS had its flaws, but it was probably the best example ever created of how one can reconcile being human-friendly with putting the filesystem front and centre as a generic concept for organizing things.

  (Sure, it had some weirdness from originating on a single-tasking machine with no permanent storage and no MMU, but you can’t beat an OS where making a bootable disk is as simple as dragging and dropping the System folder, every file and folder can have a custom icon and application developers made use of that as an aid to comprehension, file associations don’t care how you organize your programs (bugs aside), installation and removal of applications without system extensions is as simple as copying and deleting them, and the Resource Fork allows applications to have their structure without making it too easy for novices to mess things up, installing System extension was just a matter of drag-and-drop onto the System folder, removing problematic system extensions was doable via drag-and-drop without breaking things, and the equivalent to Windows Safe Mode was simply “hold Shift while booting”.)

  Heck, when I’m using it as a retro-hobby thing, the main idea I think didn’t age well is associating files with default applications on a file-by-file bases (HFS creator codes) rather than the format-by-format basis modern OSes uses… something I work around with FinderPop’s context menu for quickly re-typing files.)
• 2025-09-20 5:02 am

  ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!)

  Ugh. And I didn’t have time to apply proofreading fixes to that last paragraph I edited in. 🙁

  I should also have pointed to how much it helped that Apple created world-class HIGs, with the 1992 one for System 7 still being, in my opinion, the best example of “embody what you teach” in my entire collection of UI/UX design books and still beneficial as a broad-spectrum crash course in how to think about UI design today.

  (Assuming you see it in print. The layout doesn’t have the same kick in the PDF off the Wayback Machine archive of Apple’s developer site.)
• 2025-09-16 9:42 pm

  Flatland_Spider

  NFS mounts were also in play. Booting many systems with lots of shared parts also shaped the *nix filesystem hierarchy.

  The filesystem flexibility was an accident, but it’s a nice feature.
• 2025-09-16 11:33 pm

  Alfmanverbose=1

  Flatland_Spider,

  NFS mounts were also in play. Booting many systems with lots of shared parts also shaped the *nix filesystem hierarchy.

  The filesystem flexibility was an accident, but it’s a nice feature.

  I prefer the idea that file system abstractions primarily exist to serve us, the humans. The way the OS works behind the scene should not unnecessarily leak into the abstractions that humans see.
  While the OS needs to solve these problems, I see it as a failure that operating systems pollute human abstractions for technical reasons that human operators shouldn’t need to be bothered with.

  So under this philosophy the OS should be reshaped to fit human needs rather than the other way around.
• 2025-09-19 10:33 pm

  jgfenix

  Even if that’s the case there is some merit to it. To put the basic system utilities in one place and a small partition just like Android’s system partition can help when there is data loss or to reinstall the operating system. Although now we have immutable distributions …
8. 2025-09-16 10:06 pm

   Flatland_Spider

   It may be arcane knowledge to most users of UNIX-like systems today, but there is supposed to be a difference between /usr/bin and /usr/sbin; the latter is supposed to be for “system binaries”, not needed by most normal users. The Filesystem Hierarchy Standard states that sbin directories are intended to contain “utilities used for system administration (and other root-only commands)”, which is quite vague when you think about it. This has led to UNIX-like systems basically just winging it, making the distinction almost entirely arbitrary.

   It makes more sense in interactive multiuser systems. Most people aren’t going to need fdisk or ping, but they would need vim.

   A better interpretation is “sbin” is supposed to be for stuff which the system needs when it’s booted into single user mode. It’s an early example of a rescue OS.

   Most *nix systems are single user, or the only people logging in are admins anyway, so the split doesn’t make sense, which is why Fedora is getting rid of it.

   As such, Fedora 42 unifies /usr/bin and /usr/sbin, which is kind of a follow-up to the /usr merge, and serves as a further simplification and clean-up of the file system layout by removing divisions and directories that used to make sense, but no longer really do. Decisions like these have a tendency to upset a small but very vocal group of people, people who often do not even use the distribution implementing the decisions in question in the first place. My suggestions to those people would be to stick to distributions that more closely resemble classic UNIX.

   Anyone who gets upset about this probably isn’t running RH stuff because RH stuff has included “sbin” in the path by default for a long while. Debian has left it out, but I add it back into $PATH. 🙂

   There’s not a lot of protection on “sbin”, so anyone can run commands anyway. On the few interactive multiuser systems left, anyone cleaver enough can use the full path of those commands anyway.

   Speaking of “real UNIX”… Merging everything in “/usr” was dumb, and the reason I’ve heard is that some “real UNIX” did it that way and software expects that. It’s probably better to remember Linux is not Unix, and “until something better comes along” is part of the Unix philosophy.
9. 2025-09-17 10:27 am

   chriscox

   Eventually everything will be “/” only. Like C:. Why? To do otherwise would require us to think. And thinking is hard.
• 2025-09-17 12:03 pm

  Alfmanverbose=1

  chriscox,

  Eventually everything will be “/” only. Like C:. Why? To do otherwise would require us to think. And thinking is hard.

  Stuffing all programs into a massive directory is exactly what DOS v1 did. This was bad, as I suspect most will agree.

  c:\ <- everything goes into this directory

  Adding directories meant we could organize files into logical structures:

  c:\dos <- a bit of a heap, but understandable
  c:\games\lemmings
  c:\games\doom
  c:\games\fltsim
  c:\games\kingqust
  c:\apps\wordstar
  c:\apps\telix
  c:\apps\ripterm
  c:\utils\pkzip

  … whatever. Software could be organized and managed as the user saw fit (8 character limit was insidious, but different topic).

  Linux has subdirectories, which ought to be good, be we don’t use them effectively. I don’t mind a directory for basic system commands like /sbin c:\dos. But beyond this the *nix practice of stuffing all binaries into huge directories is highly reminiscent of DOSv1. It boggles my mind that we’ve gone so long without proper organization.

  While I criticize having /sbin /bin /usr/bin /usr/sbin /usr/local/bin, etc because their purposes are obsolete, I think people are wrongly taking this criticism to mean binaries shouldn’t be organized at all. Quite the contrary, organization is important to me, but these confusing and arbitrary linux directories are NOT creating a useful hierarchy. Creating more directories to act as massive software piles still resembles the DOSv1 situation, only now more instances of it.

  Think of a dentist office where all patient files just get stuffed into a cabinet without organization. Someone wants to fix it and buys more filing cabinets, distributing the files between them in a quasi arbitrary fashion but fails to fundamentally organize anything inside. This doesn’t fix the problem and is what linux binary directories are like today.

  I concede it’s really hard to change legacy conventions without getting people into an uproar. But are we really that committed to keeping these unorganized DOSv1-esque software piles around? This has been an ugly part of *nix I’ve wanted to fix for so long, but it’s apparent that it will require buy in from the major distros to get anything done.

• Buy OSNews merch

Search OSNEWS

OSnews Accounts

• Create Account
• Login

Topics

TopicsSelect Category.NET3DAcademic OSesAMDAmiga & AROSAndroidAppleBenchmarksBSD & DarwinBugs & VirusesClown carComicsDatabasesDebianDesktop environmentsEditorialFedora CoreFinanceFreeBSDFuchsiaGamesGeek stuffGeneral DevelopmentGenodeGentooGifts, ContestsGnomeGoogleGraphicsGTK+HaikuHardwareHealthHumorIBMIn the NewsIntelInternetInternet ExplorerJavaKDELegacy OSesLegalLinspireLinuxmacOSMandriva, Mandrake, LycorisMicrosoftMobileMonoMorphosMozilla, GeckoMultimedia, AVNetBSDNovell and XimianOfficeOpen SourceOpenBSDOpenStep, GNUstepOperaOracle and SUNOriginal OSNews InterviewsOS NewsOS/2PC-BSDPodcastsPrivacy, SecurityQNXQtReactOSRed HatRedox OSRetro computingRISC OSRumorsSCOServoSGI and IRIXSkyOSSlackware, SlaxSolarisSponsorSuSE, openSUSESyllable, AtheOSUbuntuUnixWaylandWeb 2.0WindowsWirelessXfceZeta

Related Posts

• Improving the Windows Experience with Cygwin, Version 1.3.20
  March 20, 2003 •21 Comments
• HP sends letter to muzzle Sun’s Schwartz
  October 2, 2004 •63 Comments
• Resolve Memory Leaks Using AIX 5.3
  December 12, 2006 •5 Comments
• The early Unix history of chown() being restricted to root
  October 20, 2025 •One Comment
• The HP-UX Porting and Archive Centre
  November 18, 2022 •3 Comments

Popular Posts

• Debian to add hard Rust dependency to APT
  November 2, 2025 •51 Comments
• Using Rust in Android speeds up development considerably
  November 14, 2025 •51 Comments
• “Americans are holding onto devices longer than ever and it’s costing the economy”
  November 24, 2025 •46 Comments
• “AI” assistants misrepresent news content 45% of the time
  October 24, 2025 •31 Comments
• Microsoft admits almost all major Windows 11 core features are broken
  November 24, 2025 •29 Comments

Popular Posts (Last 3 Years)

• Is 2024 the year of Windows on the desktop?
  June 20, 2024
• Rant: year of Linux on the desktop
  December 29, 2022
• Apple intentionally kills web applications for EU users in iOS 17.4 onward to spite its EU users
  February 15, 2024
• Made O’Meter helps you easily and quickly avoid American products
  March 6, 2025
• $HOME, not so sweet $HOME
  August 19, 2023