I was considering giving Alpine a try because I heard they were working on a policy that would reject LLM contributions. Looks like that hasn't landed yet?
After writing a couple of fedora specs, I've been eyeing alpine linux as an alternative. Their package format is way simpler. I have fond memories of Gentoo, but I don't want to compile distro packages from source. Alpine seems to fill the same niche but offers binary packages. Although not offering systemd poses a practical challenge, in that I would have to re-learn how to do things in OpenRC (and things like socket-activation that don't have a ready-made alternative would need glue code on a per service basis iiuc. Given that xinetd has been unmaintained for a long time).
I recently learned that Gentoo now offers more binary packages (back when I used Gentoo in the mid 2000's they only did that for a couple of packages like Firefox). So I'm also researching how Gentoo's binhost works.
IMHO Alpine Linux is hold back by OpenRC. Yes, it fast and minimal. But it's too minimal, you need supervisors, you need socket activation, it is not declarative, there has been concerns about the maintenance of it, ... This is not new, Alpine has been playing with S6 for some time, postmarketOS which is based on Alpine moved to systemd, ... I think that now that dinit exists, and ships with Chimera, they should try to move. dinit keeps some of the best things of systemd without being systemd.
I've worked at companies pushing 2% (and designed most of the OS layer) and another doing 15% of global Internet throughput and didn't miss any supervisors, socket activation, or it to be natively declarative.
I also run a traditional FreeBSD desktop and don't need any of that bullshit.
I personally agree, but the most difficult task I see in this is migration of existing installations and services. Probably not impossible but difficult. And also the social aspect, many people use Alpine because the lack of systemd.
What I imagine realistic, is to be able to choose between different initsystems/service-manger/supervisor/whatever-you-call-it.
fwiw arch packaging is quite different from alpine. I like Alpine because of its fast and user friendly package manager, which can't really be said of arch (IMO)
Interesting! I've never had issues with pacman, but I was referring to writing packages (for) yourself. I think this was what PuercoPop was referring to with writing Fedora specs. My impression (as someone who never seriously used Alpine, just from looking at docs) was that writing a PKGBUILD is about the same as writing an APKBUILD? But maybe I should give Alpine a serious try sometime.
I work a lot with Yocto (consulting). I've never encountered the problem that the post laments. It's usually the opposite: a customer goes out of their way to avoid using Yocto even when it's the best choice, and management must be convinced to use it.
That said, I think Yocto's hate is deserved. It's hard, confusing, slow, and the tooling could be better. But is there any viable alternative? Is there anything similar for the BSDs?
Haven't used it in anger and it's probably less complete than Yocto, built buildroot has some pretty good shit in it. I've mostly used it in the context of Nerves, which is basically buildroot + fwup + an Erlang VM and some support software, and I've found that to be very convenient for developing and packaging/distributing embedded linux systems.
I don't work on embedded linux/bsd systems, but having worked with NetBSD, I'd say its build system, build.sh is enough? You can easily cross-compile the kernel and a userspace with it. You might need some scripts at the end to also add some pkgsrc applications or if you have to add a bootloader like u-boot in the image you're producing. It is probably not a fully finished flow ready to be customized for your application, but a good base regardless.
The part that's missing in build.sh/pkgsrc is layer management. Unfortunately that's both the "critical feature"/the reason why a lot of people are running Yocto, and its most infuriating and hard to troubleshoot part. Then again, BSDs may not need it as badly as Linux does.
mTLS is pretty great! It does seem criminally underutilized... I feel like we've all been told to believe certificates are radioactive and should never be touched.
I like how some of the DNS RFCs define using mTLS where you verify just the public key's hash, rather than the usual cert verification (chain, SAN, expiry, etc.), e.g. RFC7858.
I do this for DNS UPDATEs to my authoritative nameserver: mTLS, verifying only the public keys, and it's supported out-the-box with the client and server tools provided by Knot DNS.
That pin flag is the client verifying the server's X509 cert's pubkey's hash (the "pin"). Knot DNS self-signed the cert and just provide you with the pin. (You can of course provide it a cert/key that is signed by a CA, if you prefer).
On the server side, Knot DNS's ACL has a cert-key field for allowlisting particular client public keys.
This gives the ease of SSH/Wireguard-style key distribution, without caring about the other fields in the cert.
Most computing professionals can't handle basic cryptography administration. The only reason HTTPS generally works is the OS/browser manage the trust store.
The idea is that your environment (your service orchestrator, your CI, your OS, ...) issues your jobs with X.509 (or JWT) credentials to authenticate against external services.
The typical implementation of "CI job with privileges" is:
I generate the CI job's credentials.
I configure the server to accept those credentials.
I upload credentials to CI.
I configure CI job to use those credentials.
This works, but has limitations:
It has many steps!
The credentials are often long lived.
The credentials are often symmetric, i.e. harder to securely distribute.
Each external service potentially requires separate credentials, and different authentication mechanisms (Basic Auth, JWT, X.509, SSH, AWS signatures, OCI signatures, ...)
With SPIFFE, my CI server will issue my CI job with credentials, e.g. a cert signed by codeberg.org with identity "tuxes/my-cool-project"
The steps becomes:
Configure server to accept those credentials (i.e. my server will allow certs signed by codeberg.org for tuxes/my-cool-project).
Configure CI job to use those credentials to authenticate to the server.
Success!
Fewer steps.
Short lived credentials: they need only last for the job's duration.
Asymmetric, i.e. you can avoid handling key material. It even be isolated in HSMs.
With network effects, clients/servers will get native support for X.509/JWT meaning the few remaining steps are trivial. Clients could even auto-discover the credentials.
At first glance it looks odd to have my server trust certs signed by codeberg.org, but the trust story is no different: my CI already knows the secrets in either case. De facto, I trust the CI server.
Of course, you can always use the existing method, or even use the SPIFFE creds to exchange for your preferred creds (and the trust story is no different).
The speed at which this was considered "done" is somewhat shocking, but I don't see it being some in motion train wreck the way this article tries to spin without hard evidence.
"When a bizarre concurrency bug appears six months from now, when some boundary condition triggers anomalous behavior under a specific load, the engineer debugging the problem will face a system that no one has ever truly understood." - pure conjecture, no facts have been brought to the table. A language port is the sweet spot for LLMs, and plenty of humans understood the base code. Why would a simple language port suddenly and irreconcilably convolute diagnostics?
An now we are all taking this claim of the "rust rewrite" at face value, as if the engineering practices in that project were so excellent that they are continuing in a long-standing tradition of good engineering practice, and there was thought and care in this "merge to master". I can also merge code to master without reviewing it, but that doesn't mean that the code will continue to work after I've done that.
I interpreted that paragraph as suggesting that the port will have ported latent bugs (either not yet discovered, or mere foot-guns), and when it happens, there won't the same institutional knowledge to diagnose it.
I could believe that could happen, but I don't think it's a train wreck. Lots of code ends up being debugged by people other than the original authors.
Yes, I have a cisco IP phone plumbed to Asterisk on my desk. I do carry an iPhone which is obviously mobile. I don't use wifi at home because I have no need for it, everything is hard wired.
Meta comes through with an entire /24 of crawlers and completely disregards robots.txt. What happened to people, "legitimate" businesses used to follow the norms and conventions of the Internet.
They realized there are no legal reproductions for violating these norms. The US government will let them do whatever they want and will never do anything to meaningfully stop them, so why would they care?
Adding scripting capabilities was a mistake, so we can avoid it now. This doesn't restrict users to have interactive programs. An example is an interactive map that is currently loaded in the browser using JavaScript so show a location of a place of interest. Instead, you can provide a Geo link to open the location in any client that supports the protocol.
So I need an app for everything again? I don't agree that scripting capabilities are a mistake per se. I do like the web as the universal platform crossing OS borders.
The advantage of using a native program to load a standardized file or URL is that it can be optimized to the device in use and prevent the "one size fits all" approach of many interactive Web pages.
I don't want to go back to the time when Linux users were a 2nd class citizen because there was only Windows support (and sometimes Mac).
I don't either, but the Web has become a VM running applications that by sheer coincidence sometimes resemble documents, and only platforms capable of running the VM get to meaningfully access it. Given the size of the VM now and the table stakes needed to support it, that becomes a substantial barrier to entry. I'm not even talking about running Chromium on NumbnutBSD on WeirdAsArchitecture, I mean even things like Ladybird on Linux/x86_64 that should be mainstream.
Ladybird on Linux/x86_64 that should be mainstream
Is this problematic? I haven't used Linux as a daily driver in quite a few years, but I thought this sort of thing wasn't a problem any more, did it get worse since I left?
Yeah. We can rant a lot about web apps, but they are the only way to dodge the Apple tax (and a potential future Google tax) when distributing apps to mobile platforms. And the situation with native desktop development is also not trivial, so I completely sympathize with people who reach for webapps or Electron on the desktop
We can rant a lot about web apps, but they are the only way to dodge the Apple tax (and a potential future Google tax) when distributing apps to mobile platforms.
The Apple tax is a political problem though, not a technical one. Web apps are already inferior to native apps on iOS. Were they to reach technical parity, Apple would institute a new tax. The entire business model of running a software distribution monopoly needs to be made illegal.
Nothing about this spec precludes you from running a normal web browser, the web as it exists now isn’t going anywhere.
Then what's the point of this? Either we improve the status quo by splitting the web platform by usecase (reducing complexity of each resulting part individually) or we use the monolithic platform as-is. Having multiple competing standards is not a very attractive goal.
I think the real sweet spot would be to figure out how much can be done with standardized markups. The problem with the modern web is it endlessly reinvents concepts, a lot of which should be declarative markups. The display path for a website really shouldn't involve Javascript. Scripting should be for specific client side programmability, like munging data sets returned from a server and things that would otherwise be done server side.
I think there's a lot of room to achieve this sort of thing by peeling apart intractably complex "web standards" like HTML/CSS into smaller, disjoint formats and protocols.
Instead of tables or complex datagrid webcomponents, make browsers understand CSV or JSONL and render them with a nice tabular UI; no need to scrape HTML to get at the underlying data, and even very rudimentary support for these formats would get you something easy to copy and paste into a local spreadsheet. Need to traverse and fetch directory trees of documents? Open an (S)FTP or Gopher client in a new tab, ideally with some affordances like rendering README.(txt|md) at the bottom of the selected directory's tree view. So many of the protocols we need already exist!
It would be great if, as a user, I could easily and seamlessly extend my web browser to support UXN rom images or display a nice hex editor for unrecognized binary formats, while the authors of the browser and the page can just think in terms of links to documents with MIME types and nested rectangles on a page. Something like the dream of user-stylesheets, but for document interpretation rather than just presentation, and segmented neatly at divisions between document types.
Years ago, we solved these problems of extending browser support for new media types with plugins- Java Applets, Flash, Shockwave, Silverlight. The plugins were platform- and browser-specific and often hosted undocumented, opaque filetypes. Today, we extend browser capabilities with the general-purpose building-blocks of JS, CSS, and HTML, and for the most part those "plugins" are inherently cross-platform, but they're delivered by the site-builders, rather than chosen by users, and the code and data of these extensions are mingled into the soup of the surrounding page.
To me, this illustrates a problem I have with forking the Web, or with Gemini---people often want their subset of features they like and want, but it's a different subset of features from person to person.
Instead of tables or complex datagrid webcomponents, make browsers understand CSV or JSONL and render them with a nice tabular UI;
Indeed HTML is designed with a nice tabular data format built in (<table>) and browsers could render it with a nice tabular UI.
I maintain that 60%+ of the problems with the web are that every popular user agent phoned it in to do the minimum baseline UX. Bad default CSS, simplest possible tables, slap in whatever native UI widget seems closest to a given form control's name, etc. But now we "can't" fix this because so many systems have been layered on top which assume these bad defaults.
I think this is more a matter of education and framework effort than anything else.
Websites (not webapps) can be done perfectly without requiring JavaScript.
Even Next.js' default project scaffolding generates a website that loads using the lynx browser!
I think it's mostly lack of awareness that this can be done and popular SPA frameworks shipping defaults that require JS, when I guess many of them can do websites that do not require JavaScript!
I don't really think this is a technical problem. Unfortunately, I don't have "solutions" for the "human" problems either :(
You always need a program for everything, it just comes in a form that your browser executes blindly (including the extreme surveillance misnamed “tracking”). So you experience that you have “one” program, the browser VM.
I would argue that in fact removing JS would reduce the number of implementations for the same thing, because you would have an incentive to interoperate and reuse what is already there. How many reimplementations of non-interoperable chat platforms do we need?
Now, I don’t have anything against cross-platform toolkits or complicated interactive programs. Use JS for that if you want. But that should not be the way we exchange mostly plain text information. Specially when we depend on that.
I’ll give you a personal example: when the electric grid failed in Spain last year, I searched on the Web from my phone what was going on. Every news site failed to load because the cell tower was overloaded and running on battery and had a poor bandwidth, so I had to get the news from a FM receiver in my old Nokia. These pages keep downloading MiBs and MiBs of JS tracking garbage code just to show me a few KiB of plain text data which is what I needed to know.
This is a failure of the current design of the Web, and I want to erradicate this from ever happening again (to me or anyone else) directly from specification.
So I need an app for everything again? I don't agree that scripting capabilities are a mistake per se. I do like the web as the universal platform crossing OS borders.
I mean, we do have an app for everything. It's just called a URL or a domain name instead of an app.
I get the impression that the IT world rallied behind the Web Browser as the VM of choice when it became clear that the available sandboxing alternatives, like Java (along with its Swing interface libraries), or even Flash (still within a browser), were painfully inferior. Now, we have a single application --- Google Chrome --- acting as that VM for the vast majority of all general purpose computing that gets done by users (that is owned and developed by a surveillance capitalist monopolist). Whether this is genuinely more secure, or whether the active zero-days are now simply too valuable to ever disclose, I don't know.
I do think adding scripting was a mistake. Or at least, it certainly was a bolted-on after-thought, and I agree with Dillo's scoping for a hypertext document reader that is not concerned with also enabling writing or editing of those documents within the reader itself:
The objective is not to create a feature-by-feature clone of the Web, but to create an specification that allows humans to exchange knowledge, notes, and other forms of information without the imposed requirement of having to run a full blown VM to read it.
I'd love to see a trimmed down "universal application" that handles the majority of the "interactive" concerns within a better sandbox. Think of something like Reddit, or any other Social Media feed. Do we really need an entire VM for pushing and pulling hypertext? Or "order an item from a store." Is an entire VM necessary for handling a shopping cart and payment information?
But alas, the "universal" tends to take over the "application" and you'd probably just re-invent The Web at that point. Maybe that would still be preferable, in that you'd have a chance for an entity besides Google --- and a language besides C++ --- to be the foundations of it (ETA: looks like Dillo is C and C++; one out of two is better than nothing I suppose :P).
With LLMs to deal with the sawtooth nature of writing Rust syntax and deal with the more elaborate type and lifetime information (something LLMs excel at) I'd say just use rust. Go has a small advantage for CLI utilities because of the stdlib coverage but the gap is small. Go completely collapses if you need to use native anything, and being able to either opt in to work stealing (async Tokio) and have extensive control over it means a lot in a production system. There is simply too much magic in Go's concepts of coroutines, GC, scheduling, network and file I/O, despite it appearing simple to the programmer.
I was an admin of the 88K based Data General Aviion line, later travelling around the country installing our software on them. The article only mentions the workstations but we had fridge sized servers with hundreds of terminals attached to them, and the first commercial RAID array in Australia (also the size of a fridge). They ran DG/UX which IMO was the best OS nobody had ever heard of in the day.
They were great machines, it’s a shame Moto dropped the 88K and DG eventually went out of business, but this was around the time of the rise of Wintel in the server room. I miss the diversity of operating systems and ideas.
Yes, the Clariion brand came later but we used them too, those systems were bulletproof. My memory is that 88K DG/UX had the best SMP of all the contemporary machines I used. I don’t know about x86 but I imagine the story was similar.
It just felt like a system that didn’t get in the way of things. It helped that it shipped with many of the GNU goodies, so I didn’t have to build them myself!
Fascinating article, thanks from sharing. The UI is more sleek than expected.
I'm also surprised Usenet seems alive - better yet, without any spam! I presume eternal-september.org might have some decent spam filters? Does anyone here use it? The discussion there looks interesting.
Renting rackspace in existing datacenters is usually a better path, they already have battery-backed power, fire suppression, climate control, and a bunch of interconnects to other networks. Coupled with some tight access-control to the building.
The economics have long favored this, and it was often ignored as businesses downsized their own on prem. There are tens of thousands of facilities that can rent at least down to the cabinet level, and some down to the rack unit, around the world. Although, to get good deals, you need to be in certain markets that have the right real estate, power, and bandwidth availability.
The one recent oddity is these extremely large players are doing on site power generation.. but if that turns out to be sustainable, it would be done at large enough colocation facilities too.
My only real experience with HP-UX, which wasn't much, was talking to the IT guy at a community college I worked with about it. The main systems, e.g. student records, were on HP-UX, but he wanted to provide mail for students and he wasn't able to get the money for another HP-UX system to do that -- so he'd slapped Slackware on an older x86 system and it was running email for the student body. This was 1998. I'd been using Linux for two years and he was the first person I'd met who also used it...
Anyway, it is sad to see things like this fade away. I do wish the author had talked in some depth about what made HP-UX special to them -- e.g., any features that were unique and interesting. I do hope someone from HPE reaches out about patches, etc. What harm could it do to provide them now?
I do wish the author had talked in some depth about what made HP-UX special to them -- e.g., any features that were unique and interesting.
Weirdly, I can’t remember HP-UX having any notable selling points, so I’m curious if that’s because I wasn’t paying attention or if it really was as metaphorically grey and lacking in eye-catching features as the appearance of the HP 9000 hardware enclosures.
I do wish the author had talked in some depth about what made HP-UX special to them -- e.g., any features that were unique and interesting.
My recollection of what was special about it was that it gave me access to some spectacular PA-RISC hardware. I don't have anything else nice to say about it personally.
I think there are two ways to approach this.. one: familiarity breeds contempt. When the code comes from some distal person or group, it's the acceptance of a gift and you may never interact with the people or community. On the other hand, when the thing has a face internally envy and jealousy would be two obvious human emotions where others that should have aligned incentives don't row in the same direction.
The other is not quite what the article is about but the Joy adage "No matter who you are, most of the smartest people work for someone else" is a funny statement that is profound. Even if you are the dominant tech company in a time, the majority of the best people work elsewhere. Therefore, some project that warrants technology fellowship across companies is probably superior to something that is simply corporate sponsored open source. Once in a while, you get a Linus Torvalds working at Transmeta type of situation but most FOSS is either composed of a larger governance body (foundations), or maybe just not that important in the overall situation.
Is it just me, or does Pg seem very high maintenance compared to other databases? For operations and tuning wise relative to SQL Server, Oracle, or Db2, anyways. Most of what I hear is constantly having to fight it (it's either time or money in the form of licensing costs, it seems).
I have heard stories about having to fight Oracle or MS SQL Server. Not much though, because I am not in the social circles of the remaining people still running those. And about PostgreSQL, there is really not much to tell until you hit the need to start tuning the parameters.
Like, my emails (and some web feeds like Lobste.rs, and like Freefall webcomics) are indexed in PostgreSQL on my laptop. Once in a few years I need to do the version migration ~five versions ahead, and last time the defaults about checksums changed (towards having checksums on by default), which the migration command explained to me, and I had to enable them on the old version then migrate. That's all there is to tell, for the last ten years.
No. I think maybe Ms SQL server and Oracle is more likely to be running on over-provisioned hardware perhaps - reducing the need for tuning somewhat.
Which makes sense - if you start with paying 10 000 USD in license fees, you're likely not trying to fit that db into an anemic vm. Postgres is free, so you might be more inclined to experiment how far down you can reasonably scale the deployment.
Relative to these commercial DBs, sure. I don't think pgsql is that much work though: turning up configuration options to match the hardware, understanding autovacuum, and having some backup/recovery strategy.. only one of these is unique.
I haven't encountered Oracle in a long time but that used to be the realm of expensive DBAs and lots of odd OS tuning and choices though.
I think it's just that PG has A LOT of knobs, but you don't really need to push them. The defaults are "good enough" most of the time. It's when you want to optimize, something developers are famous for trying to do, that you can go down giant rabbit holes and get lost in the tuning.
Years into development, Kent is still heavily refactoring things under the hood.. and apparently all of this is in preparation for a future rewrite in Rust!
I was very hopeful for bcachefs at one time, but I seriously doubt it will ever be "done" enough to use for anything.
Plenty of people are already using it in what are effectively production scenarios. Criticizing refactoring seems quite frankly bizarre - I'd be much more suspicious of a codebase in real world use that wasn't being periodically reengineered. Similarly rust feels like an obvious direction to move in, and something that couldn't sensibly happen until the rest of kernel started to accept it.
Given how few people are working on the code, and limited funding, the progress rate seems pretty decent. If you want a valid criticism, it might be that low bus factor:(
I'd be much more suspicious of a codebase in real world use that wasn't being periodically reengineered.
I wouldn't. If something worked for a decade, it's gonna work tomorrow. If something was rewritten today, it's unlikely to work the same (if at all) tomorrow. The perpetual update churn is one of the biggest causes of instability in modern computing. I would prefer a 10 years old ext4 implementation over the latest release of bcachefs any day - at least for data I care about.
If something worked for a decade, it's gonna work tomorrow.
This is a classic "it's true until it isn't" type of statement. The folks at Oxide just found a data corruption bug in ZFS that had been lurking for 18 years. Old code doesn't magically become correct, it still needs scrutiny.
Old bugs exist, for sure. But in a system that has been running without issues for a long time, by definition, they are rare or the code paths that trigger them are generally not used.
ext4 does still gain the odd feature every now and then, and fairly invasive refactorings of kernel subsystems (that entail changes to e.g. filesystems) happen reasonably often.
I do try to match the fs to the usecase though. Critical backups do indeed get stuffed on ext4. Nixos rootfses / stores go on xfs, partly because ext4 tends not to provide enough inodes for small volumes. In the past I've used btrfs for container pools etc as the subvolume support is very useful - currently migrating those to bcachefs.
Weird comment. If anything, ability to do heavy refactoring is a proof of codebase vitality.
I'm using bcachefs for 3? years as a primary fs on my workstation, it saved my data when nvme started dying, and didn't lose any data ever. Much better track record then btrfs I was using for years before then.
Same here, but I've only been using it for about 2 years.
Btrfs has been a disaster the few times I've tried it.
Bcachefs has scared me a few times (error messages from mismatching versions of kernel bcachefs vs userspace bcachfstools) but has never actually lost or corrupted any of my data. Also the few time I've contacted the devs for help (IRC) they've been super nice.
If nothing else, bcachefs has the basics right - a working fsck. btrfs has an fsck that you're basically not supposed to use. I had a drive fail in a data corrupting way this year and whole btrfs filesystems were basically instantly totally unreadable, where as bcachefs (and, tbf, ext4, xfs, etc.) repeatedly managed to recover the vast majority of the data.
I've lost some data to it sadly, after about 2 years of using it. Most of that was on a disk I used to store images, the bcachefs went readonly and corrupted a number of files. I did manage to get most data back, but before all files were rescued, the filesystem became unmountable, requiring me to pull some from backup (sadly the backup hadn't yet captured the newest files). It certainly hasn't been perfect and IMO needs some time to settle and mature, but if you have backups and can rely on them for a restore it's fine.
Are you using redundancy at least on the metadata? I really enjoy the fact that I can set these per volume, and then override per directory. Most of data on my disk can be recreated (games, OS, apps), then some extra stuff can use extra settings.
Yeah, I always setup redundant metadata or atleast checksummed metadata when the filesystem has it as option, as default and only turn it off when needed. From what I recall this was an issue with an inode getting messed up somewhere and the redundant copies where made after, so the filesystem got messed up as a whole as a result.
I seem to remember these being free, at least on this side of the millennium.
I only remember them widely used in period for k12 and community colleges. The later graduated to .edu and the former seems to have a diaspora to main TLDs.
In my lifetime, there’s been one ecosystem I deeply regret having missed out on: the Sun Microsystems ecosystem of the late 2000s.
I... don't understand. I've brushed against them half a dozen times or so during that time period, in university labs or occasional attempts at making them an (expensive) hobby. My limited experience with Sun kit made it seem very temperamental and overpriced. Compared to a linux or freebsd PC they were very much spending 10x money on a 2x better product, with userland software that was at the time mostly an out of date BSD. Sure it's cool, but...
Gonna make a lot of people upset with this, I'm sure. Sorry. CDE never sparked joy in me. Sun's real progress all happened in the 1990's and was outstripped incredibly rapidly by the internet and the companies who could keep up with it.
I can't speak for Thom but IMO a lot hinges on "ecosystem." We had Sun servers and thin clients in my University - sure, it wasn't as nice as a GNU userland, but it was a true multi-user UNIX system that showed how the classic primitives were supposed to work (cross user file sharing, talk, apache user directories, etc.). Any nostalgia is for the scenarios that were enabled by the configuration, not for the frustration of having to remember to use GNU tar to extract a gzip compressed archive.
Being shared, the setup was hardware constrained, using things like fvwm2 to support as many concurrent sessions as possible. Although Linux had nice desktop environments, hardware constraints would have prevented them. I mean, KDE/Gnome on Solaris existed too.
Agree with the 10x money on a 2x better product point. In our case it meant a 64 bit kernel with 12Gb RAM before x64, but was never going to last in a post-x64 world.
Yeah the party was definitely over by the late 2000s. The entire RISC workstation market evaporated quickly in the early 2000s, especially once AMD's Opteron hit and the combo of ATI and Nvidia graphics pushing past everything else. Linux and Windows 2000/XP offered good enough environments for these workloads so the high price was just extracting from customers who couldn't switch fast enough.
I think a lot of FOSS people came of age when x86/Linux was a given (i.e. 1990s). Talking to some older folks, the magic of Sun was before that, in the 68k and early SPARC days when SunOS was the thing. Between the bug-fixed BSD, and university outreach including SunSites, SunOS was kind of the default OS where you could grab sources online and things would just build. Things started to go down hill with Solaris, but the 1990s were such a boom time Sun did pretty well until the .com crash.
The CS department at my alma mater used real-deal UltraSPARC workstations in most of their labs at least up until I graduated in 2010. NFS home directories so you could just sit down anywhere and have your files. By comparison, working in one of the Windows labs was an exercise in pain.
I'm not some Windows fan but to be fair that was some difference in admin experience/taste. NT had similar capabilities since the mid 1990s with Domain/AD, roaming profiles, group policy, etc.
I remember the nerd rage when my alma mater KTH moved from a Unix-based mail system to one based on Microsoft products sometime in the mid 2000s. But at the time the company I worked for had migrated from a Unix-based mail system designed by what we in Sweden sarcastically call "happy amateurs" to an Exchange system run by pros, so I had bit more nuanced take on the matter.
Lets try with Data Access Patterns that our professors taught us.
We'll start with a SafeNumber.java class. Then we'll need an
add(SafeNumber b) member...Next semester we'll learn how to architect this behind Redis for webscale performance.
Since Claude made it easy, I translated the benchmark to Java and I am impressed to learn that it's only 4x slower.:
The java multiple isn't very good, maybe project valhalla will get it closer?
I was considering giving Alpine a try because I heard they were working on a policy that would reject LLM contributions. Looks like that hasn't landed yet?
FWIU the council decided against establishing said policy
https://gitlab.alpinelinux.org/alpine/council/-/work_items/697#note_615564
After writing a couple of fedora specs, I've been eyeing alpine linux as an alternative. Their package format is way simpler. I have fond memories of Gentoo, but I don't want to compile distro packages from source. Alpine seems to fill the same niche but offers binary packages. Although not offering systemd poses a practical challenge, in that I would have to re-learn how to do things in OpenRC (and things like socket-activation that don't have a ready-made alternative would need glue code on a per service basis iiuc. Given that xinetd has been unmaintained for a long time).
I recently learned that Gentoo now offers more binary packages (back when I used Gentoo in the mid 2000's they only did that for a couple of packages like Firefox). So I'm also researching how Gentoo's binhost works.
FWIW the linked comment doesn't reflect the opinion of all members of the council, just of one. And it's also not a final decision to reject a policy.
The repository (https://gitlab.alpinelinux.org/alpine/council/-/tree/master/minutes) contains the official meetings, which contain the decisions taken by the council.
IMHO Alpine Linux is hold back by OpenRC. Yes, it fast and minimal. But it's too minimal, you need supervisors, you need socket activation, it is not declarative, there has been concerns about the maintenance of it, ... This is not new, Alpine has been playing with S6 for some time, postmarketOS which is based on Alpine moved to systemd, ... I think that now that dinit exists, and ships with Chimera, they should try to move. dinit keeps some of the best things of systemd without being systemd.
I've worked at companies pushing 2% (and designed most of the OS layer) and another doing 15% of global Internet throughput and didn't miss any supervisors, socket activation, or it to be natively declarative.
I also run a traditional FreeBSD desktop and don't need any of that bullshit.
I personally agree, but the most difficult task I see in this is migration of existing installations and services. Probably not impossible but difficult. And also the social aspect, many people use Alpine because the lack of systemd.
What I imagine realistic, is to be able to choose between different initsystems/service-manger/supervisor/whatever-you-call-it.
fwiw pmOS didn't move to systemd, only merely added support to it.
You could also consider Arch: it has a similar packaging experience (PKGBUILD vs APKBUILD) and uses systemd (and glibc instead of musl).
fwiw arch packaging is quite different from alpine. I like Alpine because of its fast and user friendly package manager, which can't really be said of arch (IMO)
Interesting! I've never had issues with pacman, but I was referring to writing packages (for) yourself. I think this was what PuercoPop was referring to with writing Fedora specs. My impression (as someone who never seriously used Alpine, just from looking at docs) was that writing a PKGBUILD is about the same as writing an APKBUILD? But maybe I should give Alpine a serious try sometime.
I work a lot with Yocto (consulting). I've never encountered the problem that the post laments. It's usually the opposite: a customer goes out of their way to avoid using Yocto even when it's the best choice, and management must be convinced to use it. That said, I think Yocto's hate is deserved. It's hard, confusing, slow, and the tooling could be better. But is there any viable alternative? Is there anything similar for the BSDs?
Dunno how similar it is to Yocto, but NanoBSD is the usual way to make embedded system images from FreeBSD.
https://docs.freebsd.org/en/articles/nanobsd/
Haven't used it in anger and it's probably less complete than Yocto, built buildroot has some pretty good shit in it. I've mostly used it in the context of Nerves, which is basically buildroot + fwup + an Erlang VM and some support software, and I've found that to be very convenient for developing and packaging/distributing embedded linux systems.
I don't work on embedded linux/bsd systems, but having worked with NetBSD, I'd say its build system, build.sh is enough? You can easily cross-compile the kernel and a userspace with it. You might need some scripts at the end to also add some pkgsrc applications or if you have to add a bootloader like u-boot in the image you're producing. It is probably not a fully finished flow ready to be customized for your application, but a good base regardless.
The part that's missing in build.sh/pkgsrc is layer management. Unfortunately that's both the "critical feature"/the reason why a lot of people are running Yocto, and its most infuriating and hard to troubleshoot part. Then again, BSDs may not need it as badly as Linux does.
NetBSD is set up for cross compiles targeting limited environments, it's quite pleasant once you see it.
mTLS is pretty great! It does seem criminally underutilized... I feel like we've all been told to believe certificates are radioactive and should never be touched.
+1.
I like how some of the DNS RFCs define using mTLS where you verify just the public key's hash, rather than the usual cert verification (chain, SAN, expiry, etc.), e.g. RFC7858.
I do this for DNS UPDATEs to my authoritative nameserver: mTLS, verifying only the public keys, and it's supported out-the-box with the client and server tools provided by Knot DNS.
That pin flag is the client verifying the server's X509 cert's pubkey's hash (the "pin"). Knot DNS self-signed the cert and just provide you with the pin. (You can of course provide it a cert/key that is signed by a CA, if you prefer).
On the server side, Knot DNS's ACL has a cert-key field for allowlisting particular client public keys.
This gives the ease of SSH/Wireguard-style key distribution, without caring about the other fields in the cert.
Most computing professionals can't handle basic cryptography administration. The only reason HTTPS generally works is the OS/browser manage the trust store.
Similar convenience is coming to mTLS too: https://spiffe.io/
The idea is that your environment (your service orchestrator, your CI, your OS, ...) issues your jobs with X.509 (or JWT) credentials to authenticate against external services.
The typical implementation of "CI job with privileges" is:
This works, but has limitations:
With SPIFFE, my CI server will issue my CI job with credentials, e.g. a cert signed by codeberg.org with identity "tuxes/my-cool-project"
The steps becomes:
tuxes/my-cool-project).Success!
At first glance it looks odd to have my server trust certs signed by codeberg.org, but the trust story is no different: my CI already knows the secrets in either case. De facto, I trust the CI server.
Of course, you can always use the existing method, or even use the SPIFFE creds to exchange for your preferred creds (and the trust story is no different).
The speed at which this was considered "done" is somewhat shocking, but I don't see it being some in motion train wreck the way this article tries to spin without hard evidence.
"When a bizarre concurrency bug appears six months from now, when some boundary condition triggers anomalous behavior under a specific load, the engineer debugging the problem will face a system that no one has ever truly understood." - pure conjecture, no facts have been brought to the table. A language port is the sweet spot for LLMs, and plenty of humans understood the base code. Why would a simple language port suddenly and irreconcilably convolute diagnostics?
It's funny to me that bun was the cause of the recent claude leak according to some people: https://www.reddit.com/r/programming/comments/1s8t8hp/a_bug_in_bun_may_have_been_the_root_cause_of_the/ .
An now we are all taking this claim of the "rust rewrite" at face value, as if the engineering practices in that project were so excellent that they are continuing in a long-standing tradition of good engineering practice, and there was thought and care in this "merge to master". I can also merge code to master without reviewing it, but that doesn't mean that the code will continue to work after I've done that.
The proof like always will be in the pudding. :)
People just make things up. Boris Cherny confirmed it was not related to Bun..
I interpreted that paragraph as suggesting that the port will have ported latent bugs (either not yet discovered, or mere foot-guns), and when it happens, there won't the same institutional knowledge to diagnose it.
I could believe that could happen, but I don't think it's a train wreck. Lots of code ends up being debugged by people other than the original authors.
Hard wired everything
Even phone? I know some do that rather than wifi
Yes, I have a cisco IP phone plumbed to Asterisk on my desk. I do carry an iPhone which is obviously mobile. I don't use wifi at home because I have no need for it, everything is hard wired.
Meta comes through with an entire /24 of crawlers and completely disregards robots.txt. What happened to people, "legitimate" businesses used to follow the norms and conventions of the Internet.
They realized there are no legal reproductions for violating these norms. The US government will let them do whatever they want and will never do anything to meaningfully stop them, so why would they care?
So I need an app for everything again? I don't agree that scripting capabilities are a mistake per se. I do like the web as the universal platform crossing OS borders.
Yes, came here to say the same.
I don't want to go back to the time when Linux users were a 2nd class citizen because there was only Windows support (and sometimes Mac).
I don't either, but the Web has become a VM running applications that by sheer coincidence sometimes resemble documents, and only platforms capable of running the VM get to meaningfully access it. Given the size of the VM now and the table stakes needed to support it, that becomes a substantial barrier to entry. I'm not even talking about running Chromium on NumbnutBSD on WeirdAsArchitecture, I mean even things like Ladybird on Linux/x86_64 that should be mainstream.
Is this problematic? I haven't used Linux as a daily driver in quite a few years, but I thought this sort of thing wasn't a problem any more, did it get worse since I left?
Yeah. We can rant a lot about web apps, but they are the only way to dodge the Apple tax (and a potential future Google tax) when distributing apps to mobile platforms. And the situation with native desktop development is also not trivial, so I completely sympathize with people who reach for webapps or Electron on the desktop
The Apple tax is a political problem though, not a technical one. Web apps are already inferior to native apps on iOS. Were they to reach technical parity, Apple would institute a new tax. The entire business model of running a software distribution monopoly needs to be made illegal.
Why would you? Nothing about this spec precludes you from running a normal web browser, the web as it exists now isn’t going anywhere.
But the premise is that adding scripting was a mistake. In a world where we had not made this mistake, it is indeed an app for everything.
Then what's the point of this? Either we improve the status quo by splitting the web platform by usecase (reducing complexity of each resulting part individually) or we use the monolithic platform as-is. Having multiple competing standards is not a very attractive goal.
I think the real sweet spot would be to figure out how much can be done with standardized markups. The problem with the modern web is it endlessly reinvents concepts, a lot of which should be declarative markups. The display path for a website really shouldn't involve Javascript. Scripting should be for specific client side programmability, like munging data sets returned from a server and things that would otherwise be done server side.
I think there's a lot of room to achieve this sort of thing by peeling apart intractably complex "web standards" like HTML/CSS into smaller, disjoint formats and protocols.
Instead of tables or complex datagrid webcomponents, make browsers understand CSV or JSONL and render them with a nice tabular UI; no need to scrape HTML to get at the underlying data, and even very rudimentary support for these formats would get you something easy to copy and paste into a local spreadsheet. Need to traverse and fetch directory trees of documents? Open an (S)FTP or Gopher client in a new tab, ideally with some affordances like rendering
README.(txt|md)at the bottom of the selected directory's tree view. So many of the protocols we need already exist!It would be great if, as a user, I could easily and seamlessly extend my web browser to support UXN rom images or display a nice hex editor for unrecognized binary formats, while the authors of the browser and the page can just think in terms of links to documents with MIME types and nested rectangles on a page. Something like the dream of user-stylesheets, but for document interpretation rather than just presentation, and segmented neatly at divisions between document types.
Years ago, we solved these problems of extending browser support for new media types with plugins- Java Applets, Flash, Shockwave, Silverlight. The plugins were platform- and browser-specific and often hosted undocumented, opaque filetypes. Today, we extend browser capabilities with the general-purpose building-blocks of JS, CSS, and HTML, and for the most part those "plugins" are inherently cross-platform, but they're delivered by the site-builders, rather than chosen by users, and the code and data of these extensions are mingled into the soup of the surrounding page.
To me, this illustrates a problem I have with forking the Web, or with Gemini---people often want their subset of features they like and want, but it's a different subset of features from person to person.
If only we could have a platform which supports every possible subset, and people could restrict their authoring to the subset they want...
let's make a configurable meta-platform that can be used to create things that can either be meta-platforms themselves or restricted sub-platforms. We could call it Saṃsāra. Its bible already exists: https://www.amazon.ca/-/fr/Programming-Windows-3-1-Charles-Petzold/dp/1556153953
Indeed HTML is designed with a nice tabular data format built in (<table>) and browsers could render it with a nice tabular UI.
I maintain that 60%+ of the problems with the web are that every popular user agent phoned it in to do the minimum baseline UX. Bad default CSS, simplest possible tables, slap in whatever native UI widget seems closest to a given form control's name, etc. But now we "can't" fix this because so many systems have been layered on top which assume these bad defaults.
I think this is more a matter of education and framework effort than anything else.
Websites (not webapps) can be done perfectly without requiring JavaScript.
Even Next.js' default project scaffolding generates a website that loads using the lynx browser!
I think it's mostly lack of awareness that this can be done and popular SPA frameworks shipping defaults that require JS, when I guess many of them can do websites that do not require JavaScript!
I don't really think this is a technical problem. Unfortunately, I don't have "solutions" for the "human" problems either :(
You always need a program for everything, it just comes in a form that your browser executes blindly (including the extreme surveillance misnamed “tracking”). So you experience that you have “one” program, the browser VM.
I would argue that in fact removing JS would reduce the number of implementations for the same thing, because you would have an incentive to interoperate and reuse what is already there. How many reimplementations of non-interoperable chat platforms do we need?
Now, I don’t have anything against cross-platform toolkits or complicated interactive programs. Use JS for that if you want. But that should not be the way we exchange mostly plain text information. Specially when we depend on that.
I’ll give you a personal example: when the electric grid failed in Spain last year, I searched on the Web from my phone what was going on. Every news site failed to load because the cell tower was overloaded and running on battery and had a poor bandwidth, so I had to get the news from a FM receiver in my old Nokia. These pages keep downloading MiBs and MiBs of JS tracking garbage code just to show me a few KiB of plain text data which is what I needed to know.
This is a failure of the current design of the Web, and I want to erradicate this from ever happening again (to me or anyone else) directly from specification.
I mean, we do have an app for everything. It's just called a URL or a domain name instead of an app.
I get the impression that the IT world rallied behind the Web Browser as the VM of choice when it became clear that the available sandboxing alternatives, like Java (along with its Swing interface libraries), or even Flash (still within a browser), were painfully inferior. Now, we have a single application --- Google Chrome --- acting as that VM for the vast majority of all general purpose computing that gets done by users (that is owned and developed by a surveillance capitalist monopolist). Whether this is genuinely more secure, or whether the active zero-days are now simply too valuable to ever disclose, I don't know.
I do think adding scripting was a mistake. Or at least, it certainly was a bolted-on after-thought, and I agree with Dillo's scoping for a hypertext document reader that is not concerned with also enabling writing or editing of those documents within the reader itself:
I'd love to see a trimmed down "universal application" that handles the majority of the "interactive" concerns within a better sandbox. Think of something like Reddit, or any other Social Media feed. Do we really need an entire VM for pushing and pulling hypertext? Or "order an item from a store." Is an entire VM necessary for handling a shopping cart and payment information?
But alas, the "universal" tends to take over the "application" and you'd probably just re-invent The Web at that point. Maybe that would still be preferable, in that you'd have a chance for an entity besides Google --- and a language besides C++ --- to be the foundations of it (ETA: looks like Dillo is C and C++; one out of two is better than nothing I suppose :P).
With LLMs to deal with the sawtooth nature of writing Rust syntax and deal with the more elaborate type and lifetime information (something LLMs excel at) I'd say just use rust. Go has a small advantage for CLI utilities because of the stdlib coverage but the gap is small. Go completely collapses if you need to use native anything, and being able to either opt in to work stealing (async Tokio) and have extensive control over it means a lot in a production system. There is simply too much magic in Go's concepts of coroutines, GC, scheduling, network and file I/O, despite it appearing simple to the programmer.
This. Go is not a systems language. Period.
I was an admin of the 88K based Data General Aviion line, later travelling around the country installing our software on them. The article only mentions the workstations but we had fridge sized servers with hundreds of terminals attached to them, and the first commercial RAID array in Australia (also the size of a fridge). They ran DG/UX which IMO was the best OS nobody had ever heard of in the day.
They were great machines, it’s a shame Moto dropped the 88K and DG eventually went out of business, but this was around the time of the rise of Wintel in the server room. I miss the diversity of operating systems and ideas.
Those disk arrays led to the Clariion and were absorbed by EMC^2 which is now Dell.
I heard DG/UX had good SMP and NUMA code in its x86 form.
Yes, the Clariion brand came later but we used them too, those systems were bulletproof. My memory is that 88K DG/UX had the best SMP of all the contemporary machines I used. I don’t know about x86 but I imagine the story was similar.
It just felt like a system that didn’t get in the way of things. It helped that it shipped with many of the GNU goodies, so I didn’t have to build them myself!
I have a friend who's a fan of that era of CPU's, and she tends to say "the worst mistake any product can make is relying on Motorola".
Fascinating article, thanks from sharing. The UI is more sleek than expected.
I'm also surprised Usenet seems alive - better yet, without any spam! I presume eternal-september.org might have some decent spam filters? Does anyone here use it? The discussion there looks interesting.
When Google shut down their feeds the spam levels dropped by magnitude. It was really a face palm and sigh or relief to see them finally leave.
Yep.
There was a new committee a few years ago:
https://www.big-8.org/wiki/Main_Page
I loved those round buttons. The UI was distinct enough to stand out from the “boring” native UI but still very readable.
I would advise people to check your local zoning and codes. You also might want “enterprise-y” things like, say, fire suppression!
Renting rackspace in existing datacenters is usually a better path, they already have battery-backed power, fire suppression, climate control, and a bunch of interconnects to other networks. Coupled with some tight access-control to the building.
The economics have long favored this, and it was often ignored as businesses downsized their own on prem. There are tens of thousands of facilities that can rent at least down to the cabinet level, and some down to the rack unit, around the world. Although, to get good deals, you need to be in certain markets that have the right real estate, power, and bandwidth availability.
The one recent oddity is these extremely large players are doing on site power generation.. but if that turns out to be sustainable, it would be done at large enough colocation facilities too.
My only real experience with HP-UX, which wasn't much, was talking to the IT guy at a community college I worked with about it. The main systems, e.g. student records, were on HP-UX, but he wanted to provide mail for students and he wasn't able to get the money for another HP-UX system to do that -- so he'd slapped Slackware on an older x86 system and it was running email for the student body. This was 1998. I'd been using Linux for two years and he was the first person I'd met who also used it...
Anyway, it is sad to see things like this fade away. I do wish the author had talked in some depth about what made HP-UX special to them -- e.g., any features that were unique and interesting. I do hope someone from HPE reaches out about patches, etc. What harm could it do to provide them now?
Weirdly, I can’t remember HP-UX having any notable selling points, so I’m curious if that’s because I wasn’t paying attention or if it really was as metaphorically grey and lacking in eye-catching features as the appearance of the HP 9000 hardware enclosures.
It had a real journaling filesystem with built in volume management (not too different from ZFS) around a decade before anyone else.
It had built-in virtualization pretty early on - not the first, but long before it was common.
It ran on the Superdome massively parallel machines which meant it had to support NUMA when that was still uncommon.
It ran on Itanium (only, after they discontinued PA-RISC) and was pretty much the only OS to do that successfully.
The sad thing is that the company was allergic to open source, so none of that stuff lives on.
I remember Tru64 advfs somewhat fondly
The CPUs were often front of the pack performance wise. Even in the late 90s that might be 2-3 years ahead of x86, so they were widely used in EDA.
My recollection of what was special about it was that it gave me access to some spectacular PA-RISC hardware. I don't have anything else nice to say about it personally.
I think there are two ways to approach this.. one: familiarity breeds contempt. When the code comes from some distal person or group, it's the acceptance of a gift and you may never interact with the people or community. On the other hand, when the thing has a face internally envy and jealousy would be two obvious human emotions where others that should have aligned incentives don't row in the same direction.
The other is not quite what the article is about but the Joy adage "No matter who you are, most of the smartest people work for someone else" is a funny statement that is profound. Even if you are the dominant tech company in a time, the majority of the best people work elsewhere. Therefore, some project that warrants technology fellowship across companies is probably superior to something that is simply corporate sponsored open source. Once in a while, you get a Linus Torvalds working at Transmeta type of situation but most FOSS is either composed of a larger governance body (foundations), or maybe just not that important in the overall situation.
Is it just me, or does Pg seem very high maintenance compared to other databases? For operations and tuning wise relative to SQL Server, Oracle, or Db2, anyways. Most of what I hear is constantly having to fight it (it's either time or money in the form of licensing costs, it seems).
I have heard stories about having to fight Oracle or MS SQL Server. Not much though, because I am not in the social circles of the remaining people still running those. And about PostgreSQL, there is really not much to tell until you hit the need to start tuning the parameters.
Like, my emails (and some web feeds like Lobste.rs, and like Freefall webcomics) are indexed in PostgreSQL on my laptop. Once in a few years I need to do the version migration ~five versions ahead, and last time the defaults about checksums changed (towards having checksums on by default), which the migration command explained to me, and I had to enable them on the old version then migrate. That's all there is to tell, for the last ten years.
No. I think maybe Ms SQL server and Oracle is more likely to be running on over-provisioned hardware perhaps - reducing the need for tuning somewhat.
Which makes sense - if you start with paying 10 000 USD in license fees, you're likely not trying to fit that db into an anemic vm. Postgres is free, so you might be more inclined to experiment how far down you can reasonably scale the deployment.
Relative to these commercial DBs, sure. I don't think pgsql is that much work though: turning up configuration options to match the hardware, understanding autovacuum, and having some backup/recovery strategy.. only one of these is unique.
I haven't encountered Oracle in a long time but that used to be the realm of expensive DBAs and lots of odd OS tuning and choices though.
I think it's just that PG has A LOT of knobs, but you don't really need to push them. The defaults are "good enough" most of the time. It's when you want to optimize, something developers are famous for trying to do, that you can go down giant rabbit holes and get lost in the tuning.
The benefit of hosted is getting accessed to closed source distributed DBs like Aurora and AlloyDB. I never understood the appeal to RDS/CloudSQL.
Years into development, Kent is still heavily refactoring things under the hood.. and apparently all of this is in preparation for a future rewrite in Rust!
I was very hopeful for bcachefs at one time, but I seriously doubt it will ever be "done" enough to use for anything.
Plenty of people are already using it in what are effectively production scenarios. Criticizing refactoring seems quite frankly bizarre - I'd be much more suspicious of a codebase in real world use that wasn't being periodically reengineered. Similarly rust feels like an obvious direction to move in, and something that couldn't sensibly happen until the rest of kernel started to accept it.
Given how few people are working on the code, and limited funding, the progress rate seems pretty decent. If you want a valid criticism, it might be that low bus factor:(
I wouldn't. If something worked for a decade, it's gonna work tomorrow. If something was rewritten today, it's unlikely to work the same (if at all) tomorrow. The perpetual update churn is one of the biggest causes of instability in modern computing. I would prefer a 10 years old
ext4implementation over the latest release ofbcachefsany day - at least for data I care about.This is a classic "it's true until it isn't" type of statement. The folks at Oxide just found a data corruption bug in ZFS that had been lurking for 18 years. Old code doesn't magically become correct, it still needs scrutiny.
Not only that, but there are so, so many examples of code that worked but needed to be re-written because there was a time limit before they hit a known failure state. Here are the most obvious well-known examples: https://en.wikipedia.org/wiki/Year_2000_problem https://en.wikipedia.org/wiki/Year_2038_problem
Old bugs exist, for sure. But in a system that has been running without issues for a long time, by definition, they are rare or the code paths that trigger them are generally not used.
ext4 does still gain the odd feature every now and then, and fairly invasive refactorings of kernel subsystems (that entail changes to e.g. filesystems) happen reasonably often.
I do try to match the fs to the usecase though. Critical backups do indeed get stuffed on ext4. Nixos rootfses / stores go on xfs, partly because ext4 tends not to provide enough inodes for small volumes. In the past I've used btrfs for container pools etc as the subvolume support is very useful - currently migrating those to bcachefs.
Weird comment. If anything, ability to do heavy refactoring is a proof of codebase vitality.
I'm using bcachefs for 3? years as a primary fs on my workstation, it saved my data when nvme started dying, and didn't lose any data ever. Much better track record then btrfs I was using for years before then.
Same here, but I've only been using it for about 2 years.
Btrfs has been a disaster the few times I've tried it.
Bcachefs has scared me a few times (error messages from mismatching versions of kernel bcachefs vs userspace bcachfstools) but has never actually lost or corrupted any of my data. Also the few time I've contacted the devs for help (IRC) they've been super nice.
If nothing else, bcachefs has the basics right - a working fsck. btrfs has an fsck that you're basically not supposed to use. I had a drive fail in a data corrupting way this year and whole btrfs filesystems were basically instantly totally unreadable, where as bcachefs (and, tbf, ext4, xfs, etc.) repeatedly managed to recover the vast majority of the data.
I've lost some data to it sadly, after about 2 years of using it. Most of that was on a disk I used to store images, the bcachefs went readonly and corrupted a number of files. I did manage to get most data back, but before all files were rescued, the filesystem became unmountable, requiring me to pull some from backup (sadly the backup hadn't yet captured the newest files). It certainly hasn't been perfect and IMO needs some time to settle and mature, but if you have backups and can rely on them for a restore it's fine.
Are you using redundancy at least on the metadata? I really enjoy the fact that I can set these per volume, and then override per directory. Most of data on my disk can be recreated (games, OS, apps), then some extra stuff can use extra settings.
Yeah, I always setup redundant metadata or atleast checksummed metadata when the filesystem has it as option, as default and only turn it off when needed. From what I recall this was an issue with an inode getting messed up somewhere and the redundant copies where made after, so the filesystem got messed up as a whole as a result.
That shouldn’t be an obstacle for the open source kernel that is infamous for code churn and the inability to keep any internal interface stable.
It’s irrelevant to “the open source kernel”.
You just described the Linux development process though.
I seem to remember these being free, at least on this side of the millennium.
I only remember them widely used in period for k12 and community colleges. The later graduated to .edu and the former seems to have a diaspora to main TLDs.
I... don't understand. I've brushed against them half a dozen times or so during that time period, in university labs or occasional attempts at making them an (expensive) hobby. My limited experience with Sun kit made it seem very temperamental and overpriced. Compared to a linux or freebsd PC they were very much spending 10x money on a 2x better product, with userland software that was at the time mostly an out of date BSD. Sure it's cool, but...
Gonna make a lot of people upset with this, I'm sure. Sorry. CDE never sparked joy in me. Sun's real progress all happened in the 1990's and was outstripped incredibly rapidly by the internet and the companies who could keep up with it.
I can't speak for Thom but IMO a lot hinges on "ecosystem." We had Sun servers and thin clients in my University - sure, it wasn't as nice as a GNU userland, but it was a true multi-user UNIX system that showed how the classic primitives were supposed to work (cross user file sharing, talk, apache user directories, etc.). Any nostalgia is for the scenarios that were enabled by the configuration, not for the frustration of having to remember to use GNU tar to extract a gzip compressed archive.
Being shared, the setup was hardware constrained, using things like fvwm2 to support as many concurrent sessions as possible. Although Linux had nice desktop environments, hardware constraints would have prevented them. I mean, KDE/Gnome on Solaris existed too.
Agree with the 10x money on a 2x better product point. In our case it meant a 64 bit kernel with 12Gb RAM before x64, but was never going to last in a post-x64 world.
Yeah the party was definitely over by the late 2000s. The entire RISC workstation market evaporated quickly in the early 2000s, especially once AMD's Opteron hit and the combo of ATI and Nvidia graphics pushing past everything else. Linux and Windows 2000/XP offered good enough environments for these workloads so the high price was just extracting from customers who couldn't switch fast enough.
I think a lot of FOSS people came of age when x86/Linux was a given (i.e. 1990s). Talking to some older folks, the magic of Sun was before that, in the 68k and early SPARC days when SunOS was the thing. Between the bug-fixed BSD, and university outreach including SunSites, SunOS was kind of the default OS where you could grab sources online and things would just build. Things started to go down hill with Solaris, but the 1990s were such a boom time Sun did pretty well until the .com crash.
The CS department at my alma mater used real-deal UltraSPARC workstations in most of their labs at least up until I graduated in 2010. NFS home directories so you could just sit down anywhere and have your files. By comparison, working in one of the Windows labs was an exercise in pain.
I'm not some Windows fan but to be fair that was some difference in admin experience/taste. NT had similar capabilities since the mid 1990s with Domain/AD, roaming profiles, group policy, etc.
I remember the nerd rage when my alma mater KTH moved from a Unix-based mail system to one based on Microsoft products sometime in the mid 2000s. But at the time the company I worked for had migrated from a Unix-based mail system designed by what we in Sweden sarcastically call "happy amateurs" to an Exchange system run by pros, so I had bit more nuanced take on the matter.