And now GNU/Linux is freely taking money from corporate overlords and ponying up money to frontier model companies. I don't know what possess people to think Linux is still some cool counter culture thing, it's not. It's just still wearing the mask of one because people have selective hearing.
I can't speak on everyones behalf and I am not just referencing Linux here, I am also referencing the great family of BSDs, but having the full source available as part of the install is what I'm all about. If that is _counter cultural_ then so be it, but it isn't the main intent. But having the source to the kernel, the OS, the apps I use, complete with stellar man pages and other manuals... I'm set.
From the article:
>When an individual chooses to use a Linux-based operating system instead of Windows or OSX, they are, deliberately or not, making a statement. They are declaring themselves to be autonomous and independent.
But this is being reversed now and this has gradually been the case over the years. By just using linux are you capable of debugging the kernel? When the code itself grows unbounded in size and complexity, the moat grows more and more. Tomorrow if you had a nasty GPU driver bug or scheduler bug in any of these systems are you personally empowered to make that change? I would argue no. I've had this, I've tried trawling through the kernel to help some nerds debug why ppc64 KVM was not working when running in BE mode and it was completely intractable. I could just be an idiot though, the evaluation of that is left to the reader.
My point with referencing with LLMs is that this has turned this dial up to 11, now you have developers shipping a crap ton of code and complexity is growing more. The more the developers rely on this stuff the more there is this kind of implication that in order for you to keep up you will use it too. Is that carrying the spirit of the luddite?
Also FreeBSD is also taking LLM stuff, OpenBSD doesn't have a policy prohibiting this, NetBSD does.
Congrats to the team, I adore Haiku from afar and hope they continue to do good work. Had to do a bit of debugging with some code I help maintain for the new release, but it was a fun excuse to mess around with it a bit again.
Just in time for the kernel and its consequences to become completely hostile to anyone not paying for a frontier model. If I was 16 again and evaluating linux only to see everyone using LLMs to reason about the mess they've put themselves in I don't know if I would have even bothered. The promise of "you can just read and learn about it yourself" has been dead for at least 10 years, but LLMs put the nail in the coffin.
Linux has gone from attracting hippies to openly endorsing corporate closed-source products, something something live long enough to become the villain.
When did you get the idea that we're trying to please anyone? The type of people to scream about "wokerism" are not the folks we want in our community, conversely the people who scream that we're not sufficiently sanitized for them to put on their corporate website are also not who we want. The system is working as designed, we take no pain in 9front not being for you.
The deadly combination of people on the autistic spectrum tending to miss humour, especially subtle humour, even more so when it references things outside their narrow cultural window...
... Combined with American dislike, and lack of comprehension, of sarcasm and irony.
>When did you get the idea that we're trying to please anyone?
Ah, I see. Those footer flags and icons are there for ironic reasons, to poke fun at these ideas while also shining a critical spotlight on them? I see, that's the dark humor I like.
>sufficiently sanitized for them to put on their corporate website are also not who we want.
I'm pretty sure it's possible in Silicon Valley, but only for one month of the year. It's just performative AF.
But at least you split the Ukrainian in half and exchange it with the US one, again....that's the really dark humor i like.
After all of this hype this is the best they can do? This is the forefront company (arguable) of the forefront tech and no one can review slides before being shipped out? I think the reason why this has resonated with people is that it gives a "vibe" of not giving a shit, they'll ship whatever next slop generator they want and they expect people to gladly lap it up. Either that or they're using their own dog food and the result is this mess. Do the stats even matter anymore? Is that what they're banking on?
the distributed computing model is pretty nice in theory (maybe not in practice) and the uniform system APIs are also nice. The userspace tools in particular are just plain better (structured regex commands are quite a bit better than ed-style and I find myself using them far more frequently in vis than I do in vim, they're far more composable and intuitive).
The biggest thing is the heavy reliance on union file systems (and file systems in general) and an extremely simple syscall API. It's a heterogeneous-networked-node OS so it handles realistic workloads natively with primitives designed for it instead of piling complexity on top of Unix-like APIs (ie. Linux). I dunno, I just think a lot of the modern "cloud native" stack is unnecessary if you had an OS actually built for the workloads we have.
There aren't really union filesystems per se, the plan 9 kernel provides unions through its namespace model. In my opinion part of the reason why the userspace tools can be as nice as they are, are due to the use of file system interfaces and the simplistic syscall API. Could you elaborate more on the issues you see with the use of these?
In regards to using it for a "cloud native" stack, the issue is that people want to run code that isn't designed for Plan 9. You could build whatever backplane type thing you want out of plan 9 but the end goal is still likely to be to run some web app or REST api server. Unless someone does a great deal of effort to port all of those environments that people want (nodejs, modern python, etc) you're going to be stuck using a VM and losing a lot of the benefit.
This feels similar to what Joyent did with lxzones in SmartOS, where the backplane was solaris based but the apps they were running for clients were using Linux. It's hard to make the plan 9 backplane better enough to warrant dealing with integrating the guest and host environment.
> Unless someone does a great deal of effort to port all of those environments that people want (nodejs, modern python, etc) you're going to be stuck using a VM and losing a lot of the benefit.
It should not be a huge deal of effort since as you mention the plan9 syscall API is simpler than on Linux. The added plan9 support could then also serve as a kind of "toy" backend that could make the rest of the code more understandable in other ways.
I'd even argue that OP's early experiment with such a port of tailscale shows precisely such an outcome.
> There aren't really union filesystems per se, the plan 9 kernel provides unions through its namespace model.
Yes, this is what I'm referring to. It's really many filesystems unioned into one namespace that is controllable per-process.
> In my opinion part of the reason why the userspace tools can be as nice as they are, are due to the use of file system interfaces and the simplistic syscall API. Could you elaborate more on the issues you see with the use of these?
I didn't say I had any issues, I said I preferred them! Aside from a lack of familiarity and needing to install plan9ports on other systems, I haven't had issues.
> In regards to using it for a "cloud native" stack, the issue is that people want to run code that isn't designed for Plan 9. You could build whatever backplane type thing you want out of plan 9 but the end goal is still likely to be to run some web app or REST api server.
Right, language support is the biggest issue with running on Plan 9 from that perspective, at least for "server" workloads. Excluding graphical APIs, the basic stuff (file IO, networking, etc.) isn't all that hard to add to a language (it of course depends). The real trouble is things that have no equivalent in Plan 9, such as mmap and shm.
> This feels similar to what Joyent did with lxzones in SmartOS, where the backplane was solaris based but the apps they were running for clients were using Linux.
This is also what Oxide is doing. Their rack's OS is IllumOS but their customers are expected to only interface with the OS via their tooling and instead provision VMs.
> It's hard to make the plan 9 backplane better enough to warrant dealing with integrating the guest and host environment
If I were doing it, I would do it the other way! Run Plan 9 in a backplane/hypervisor and target it from the language level. The nice part is the systems programming model!
> Excluding graphical APIs, the basic stuff (file IO, networking, etc.) isn't all that hard to add to a language (it of course depends).
You could implement a modern graphical API on top of virtio-gpu, which would give you low-level access to accelerated graphics.
> The real trouble is things that have no equivalent in Plan 9, such as mmap and shm.
Some uses of mmap and shm actually seem to have a near-equivalent already in plan9's segattach. Other uses would require some implementation of distributed shared memory (i.e. implementing the usual CPU concurrency model over the network) to be made feasible while keeping to the usual networked-OS focus of plan9.
Right, you could do it... maybe. Some languages/libraries/runtimes could have specific expectations around the specifics of mmap that can't easily be papered over, but I suspect it would be a minority of cases
It could be used to replace k8s-based deployments (also Docker Swarms, etc.) since system interfaces on Plan 9 are namespaced and containerized "out-of-the-box" as part of its basic design (and this is one of the most prominent additions compared to *NIX). It's not a hacked-on feature as with Linux.
Yes you're correct, my apologies. There has been work on this going the other way as well: https://github.com/michaelforney/wl9. But there's still a lot more than can be done. There are vague plans to test the waters implementing something like this in to our vmx(1).
As the sibling comment has mentioned Unicode in DNS uses a punycode encoding but even further then that the standard specifies that the Unicode data must be normalized to NFC[0] before being converted to punycode. This means that your second example (decomposed e with combining acute accent vs the composed variant) is not a valid concern. The Cyrillic one is however.
[0] https://www.rfc-editor.org/rfc/rfc5891 § 4.1 "By the time a string enters the IDNA registration process as described in this specification, it MUST be in Unicode and in Normalization Form C"
Sure, but the security concerns of that I feel are much less concerning than having multiple domain names with the same visual appearance that point to different servers. That has immediate impact for things like phishing whereas lookalike path or query portions would at least ensure you are still connecting to the server that you think you are.
Normalization implementations must not strip variation selectors by definition. The "normal" part of normalization means to convert a string into either consistently decomposed unicode, or composed unicode. ie U+00DC vs U+0055 + U+0308. However this decomposition mapping is also used (maybe more like abused) for converting certain "legacy" code points to non-legacy code points. There does not exist a rune which decomposes to variant selectors (and thus these variant selectors do not compose into anything) so normalization must not alter or strip them.
source: I've implemented Unicode normalization from scratch
reply