161–170 of 312 posts
Ubuntu was always "let's just fuck up what just works in Debian" but this is another level, I have no idea why they are rushing it
Distros using Ubuntu as base should reconsider.
Earlier quoted context omitted.
C++ ABI stability is the main reason improvements to the language get rejected. You cannot change anything that would affect the class layout of something in the STL. For templated functions where the implementation is in the header, ODR means you can't add optimizations later on. Maybe this was OK in the 90s when companies deleted the source code and laid off the programmers once the software was done, but it's not…
I think if Rust wants to evolve even more aggressively than C++ evolves, then that is a chasm that needs to be crossed. In lots of domains, having a language that doesn't change very much, or that only changes very carefully with backcompat being taken super seriously, is more important than the memory safety guarantees Rust offers.
So far mostly that they pushed untested tools that even authors didn't think are production ready on ususpecting users. Ubuntu was always "let's just fuck up what just works in Debian" but this is another level, I have no idea why they are rushing it Distros using Ubuntu as base should reconsider.
Also, Ubuntu using a non-GPL licensed userland means they can pull all kinds of tricks to allow more TiVoization in the Linux ecosystem. Combine this with what Amutable (systemd guys) are building, and you can have monolithic, closed source, non-user-modifiable Linux distributions or flavors. Ubuntu and companies which embed Linux into their products will love this from a business perspective. Consider: An end to end…
People complain about AWS and others taking OSS projects and profiting wildly off them, but they're all children compared to the machinations of Ubuntu.
It's been this way from the start. The constant conflict of interest, where Ubuntu devs manipulate debian democratic processes, and the inclusion of systemd and its ridiculous swiss-army-knife implementation of an init system and surrounding tools.
You ever see those knives, the huge ones, with a screwdriver, plyers, and 100 other tools on them? Thing is, they're all crap. They work for an odd case, but you always need to reach for a real tool.
That's systemd. Whether systemd-timesync, its dns services, or anything else it does, it's kiddie time. Barely functional, broken in inane ways, and leaving any professional in a situation of endless masking of a myriad of barely cogent and horribly malign services.
We didn't gain anything with systemd, except for an init system 1000 times larger, codebase wise, and a collection of tools you have to replace anyhow.
And now these guys want to do Amutable. I hope they fail, for if they succeed, they will sink us further into this absurd system. Systemd for death. For despair. For dislike. For dumb. For disregard, devilment, debased, disturbed, systemd is all these things, and more, all packaged for you, all presented to you, all given to you, to all of us, dragging us down, destroying us.
If there is an apocalypse, it'll be somehow some bug in systemd that causes it. Nukes will fly due to its broken code, viral containment systems will fail due to buffer overruns in its code, systemd is the end-of-world waiting to happen, its over-complicated, poorly written code a guillotine waiting to fall upon us all.
I run thousands of sysvinit, and thousands of systemd systems.
Which ones, do you think, have the worse record of "something stupid" bringing down a service, a machine, preventing a boot up, you name it, it's systemd.
I swear to God that Trump exists because of systemd somehow. I place all the ills, perils, at the feet of systemd. It represents everything wrong in the tech ecosystem, its tendrils spreading dark, deep disturbing dreams of madness through all it touches.
Just learning how to use systemd, destroys the logic centres of the mind, rendering advocates incapable of productive work.
All wrong and ill that befalls this world, is at its feet.
I suspect through some incomprehensible twist of fate, the entire fabric of the universe may unravel, undoing all that is, and ever was. All lost, all gone, all because of systemd.
I am beginning to suspect I dislike systemd.
(Send $19.95 to my address, if you wish to subscribe to my newsletter, and hear my REAL, UNFILTERED opinions about systemd)
Earlier quoted context omitted.
> Until that happens, it'll be hard to adopt Rust in a lot of C/C++ strongholds where C's ABI and dynamic linking are the thing that enables the software to get huge. Wait, Rust can already communicate using the C ABI. In fact, it offers exactly the same capabilities as C++ in this regard (dynamic linking).
That's an unsafe ABI.
Ubuntu used to be the distro to go do, used to. - SNAP which is only managed and supported by them - Tried to reinvent the wheel with sudo-rs - They are heavily focused into cloud, servers and business - Following the Rust hype train I used Ubuntu for 13y or so, it is a Windows within Linux world. Bloated, kernel panic, heavy, privacy issues. Debian still the king to be used as servers, Mint Cinnamon is the king for…
reinvent how? sudo-rs and a bunch of others are maintained by: https://trifectatech.org/ a non profit registered in Netherlands
Earlier quoted context omitted.
That would be great, but Rust relies on compile-time monomorphization for efficiency (very much like C++, if you consider templates polymorphic functions/classes). This means that any Rust ABI would have to cater for link-time specialization. I think this should be doable, but it would require a solution that's better than just to move the code generation into the linker. Instead, one would need to carefully consider…
I wonder if we look at it from a too narrow perspective. We use the C ABI because it's the only game in town. We should be aiming for a safe cross language ABI. I'd love to make Rust, C, PHP, Swift, Java and Python easily talk to each other inside 1 process. It should extend the C ABI with things like strings, arrays, objects with a way to destruct them, and provide some safety guarantees. As an example, the windows…
Earlier quoted context omitted.
This might end up being the forcing function (quoting myself from another reply in this discussion): > It can't be that replacing 20 C/C++ shared objects with 20 Rust shared objects results in 20 copies of the Rust standard library and other dependencies that those Rust libraries pull in. But, today, that is what happens. For some situations, this is too much of a memory usage regression to be tolerable. If memory wa…
Can you even make the standard library dynamically linked in the C way?? In C, a function definition usually corresponds 1-to-1 to a function in object code. In Rust, plenty of things in the stdlib are generic functions that effectively get a separate implementation for each type you use them with. If there's a library that defines Foo but doesn't use VecFoo>, and there are 3 other libraries in your program that do u…
Earlier quoted context omitted.
How could a safe dynamic linking API ever work? I think you're moving the goalposts significantly here.
I don’t think GP is moving the goalposts at all, rather I think a lot of people are willfully misrepresenting GP’s point. Rust-to-rust code should be able to be dynamically linked with an ABI that has better safety guarantees than the C ABI. That’s the point. You can’t even express an Option via the C ABI, let alone the myriad of other things rust has that are put together to make it a safe language. You can look to…
But you can express Option for a concrete Foo. Do you really need any more than that?
Also, Ubuntu using a non-GPL licensed userland means they can pull all kinds of tricks to allow more TiVoization in the Linux ecosystem. Combine this with what Amutable (systemd guys) are building, and you can have monolithic, closed source, non-user-modifiable Linux distributions or flavors. Ubuntu and companies which embed Linux into their products will love this from a business perspective. Consider: An end to end…