|
|
Subscribe / Log in / New account

Oh FFS!

Oh FFS!

Posted Nov 24, 2024 16:44 UTC (Sun) by mirabilos (subscriber, #84359)
Parent article: NonStop discussion around adding Rust to Git

Rust is an inside job to kill FOSS.

It is getting close to succeeding to turning me off of FOSS, and I’ve been fucking *living* FOSS for about ⅔ of my life (and not limited to software either).


to post comments

Oh FFS!

Posted Nov 24, 2024 17:12 UTC (Sun) by intelfx (subscriber, #130118) [Link] (5 responses)

> It is getting close to succeeding to turning me off of FOSS

If Rust is turning you off of FOSS, then you probably weren’t attracted to it in the first place. You were merely attracted to the status quo.

Oh FFS!

Posted Nov 24, 2024 17:48 UTC (Sun) by mirabilos (subscriber, #84359) [Link] (4 responses)

Nonsense.

(Meanwhile, the IRC channel where this popped up has more people expressing disbelief in this “cult”.)

Oh FFS!

Posted Nov 24, 2024 18:52 UTC (Sun) by intelfx (subscriber, #130118) [Link]

> Nonsense.

Your original posting did not carry much sense either.

> (Meanwhile, the IRC channel where this popped up has more people expressing disbelief in this “cult”.)

If you happen to dislike something, or dislike those who disagree with you, that does not make it a cult. So far you have provided zero rational reasons for your displeasure, which makes _your_ position much closer to a “cult” than the one you argue against.

Oh FFS!

Posted Nov 25, 2024 8:44 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

But WHAT is turning you off FLOSS?

Is it Rust itself, or is it all the luddites throwing up the barricades against Rust?

(And for the record, from what I'm picking up, most of the key people aren't what we think of as luddites - although they may have a lot in common with the original Luddites who were skilled workers facing watching their skills become obsolete - and I think a lot of them would welcome it if it weren't for the high *personal* cost associated with it.)

Cheers,
Wol

Oh FFS!

Posted Nov 25, 2024 12:06 UTC (Mon) by pizza (subscriber, #46) [Link] (1 responses)

> Is it Rust itself, or is it all the luddites throwing up the barricades against Rust?

You left out "Or the obnoxious rust in everything and everything is magically better in rust!!!!!111" advocates?

Oh FFS!

Posted Nov 25, 2024 13:46 UTC (Mon) by Wol (subscriber, #4433) [Link]

Yep. There seems to be a lot of that.

But as I see it, most of the people who are actually USING rust seem to be the friendly "come in and join us" types.

And most of the people USING C are just "oh no not even MORE work that I'm expected to do without getting paid" types.

It's all the empty vessels that are the problem (that and the odd personality clash).

Cheers,
Wol

Oh FFS!

Posted Nov 24, 2024 18:35 UTC (Sun) by jrtc27 (subscriber, #107748) [Link] (35 responses)

All current Rust compilers, including the reference/official one, and the standard library are under FOSS licenses, and any Rust code you write can be under the exact same FOSS license as existing C or C++. As with any technology there are legitimate criticisms you can make of it, but "an inside job to kill FOSS" is just not in any way true.

Oh FFS!

Posted Nov 24, 2024 19:13 UTC (Sun) by viro (subscriber, #7872) [Link] (6 responses)

I can't speak for mirabilos, obviously, but my impression is that the problem is not with technology - it's with the fanboys. Evangelists tend to induce a gag reflex, regardless of the subject they cover with, er, sticky evidence of their devotion...

Oh FFS!

Posted Nov 24, 2024 19:49 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> Evangelists tend to induce a gag reflex

Like, those Linux hippies?

Oh FFS!

Posted Nov 24, 2024 21:09 UTC (Sun) by viro (subscriber, #7872) [Link] (3 responses)

I don't know about hippies, but if you are talking about Linux advocates - yes, absolutely. Starting with the regular sight of comp.os.linux.advocacy threads cross-posted to hell and back, unfortunately including c.o.l.development.*, full of the holy warriors with not a single clue between them judging by the quality of information they'd been posting. Gag reflex - you bet.

FWIW, I carefully keep my impression regarding Rust separate from anything induced by Rust advocates/awareness raisers/evangelists/etc. It takes conscious efforts (revulsion tends to spread along the associations), but that's the only way to keep sanity, IME.

Oh FFS!

Posted Nov 25, 2024 6:54 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

I don't mind over-enthusiastic fanboys/fangirls (fanpersons?). They help to move the industry forwards, even if their enthusiasm is often misguided and/or naïve (cue the crypto folks). And sometimes they DO end up being right.

And hey, I do like a good flame once in a while.

Oh FFS!

Posted Nov 25, 2024 8:19 UTC (Mon) by josh (subscriber, #17465) [Link]

> FWIW, I carefully keep my impression regarding Rust separate from anything induced by Rust advocates/awareness raisers/evangelists/etc.

That's greatly appreciated. Rust folks don't like the RESF either, and have on multiple occasions said "please stop doing that, it isn't helping".

Oh FFS!

Posted Nov 25, 2024 18:10 UTC (Mon) by khim (subscriber, #9252) [Link]

> FWIW, I carefully keep my impression regarding Rust separate from anything induced by Rust advocates/awareness raisers/evangelists/etc. It takes conscious efforts (revulsion tends to spread along the associations), but that's the only way to keep sanity, IME.

I could only agree with that. What I hate most about fanboys/fangirls (fanpersons?) is their tendency to completely ignore failures of something try try to “promote” – yet the very moment when said failures are overcome they suddenly turn into a selling point.

I'm not capable of doing that. I hated certain decisions that Rust did and still hate some aspects of it, but they fixed it's deficiencies well enough that I have to admit that Rust is currently the best language for low-level work – even in spite of colored functions, lack of reflections, complicated metaprogramming and everything…

Is it perfect? Absolutely not. But exists, it works, it delivers. And I can live with it's deficiencies, even if just barely, in some cases.

But try to tell that to a fanboy/fangirl (fanperson?)! They would immediately tar you with feathers, declare that you don't know enough of the theory to judge that perfect creation, etc.

I, sometimes, feel that fanboys/fangirls (fanpersons?) could be the biggest imediment to the Rust adoption… but the cure is simple: just talk to actual people who develop Rust… these guys and gals very often would accept you complains and would explain why certain things are done in the way you hate… and you may even understand why this or that compromise was made.

Apropos the local Victorian Sufi Buddha

Posted Nov 24, 2024 20:07 UTC (Sun) by tux3 (subscriber, #101245) [Link]

Here's what I see when I try to post a comment:

>Enter your comment text below. Before posting, though, please consider:
>
> - Is your comment polite, respectful, and informative?
> - Are you saying something new that extends the conversation?
> - Have you provided a useful subject line?

I suppose different sites have different comment policy. Some places ask for kind, truthful, and necessary. The local version says polite, respectful, and informative.

Was it really necessary for people, on this Sunday evening, to be subject to this kind of tawdry comparison.

Oh FFS!

Posted Nov 24, 2024 21:27 UTC (Sun) by mirabilos (subscriber, #84359) [Link] (27 responses)

It’s great for corporate monoculture FOSS, I’m sure.

“Here’s the multi-million-LoC codebase which depends on another multi-million-LoC codebase (LLVM, see below), surely you have no problems using it, it’s open source after all!”

Too bad when you’re a hobbyist OS (not even mine, but I know the founder personally) that wants to add a small patch, which doesn’t even touch other platforms, to LLVM to add support for his OS, because if you’re in that situation you get rejected unless you shell over money in the ballpark of 300 $/month from your hobbyist budget so that LLVM can run CI on your OS. (And he was “lucky” enough that that would even have been possible and this cheap, as it’s on amd64; imagine wanting to write an OS for SPARC or MMIX or whatever that *doesn’t* have quick VMs).

Now go back to when Torvalds wrote Linux. Do you think it could have gotten off the ground having to meet such insane requirements?

And while not all hobbyist OSes bring as much to the table as Linux, evidently some quite do. (I’m seeing lots of Plan 9 influence recently, in rather many places as well, to name one.)

Sometimes, feasibility studies are being made as hobbyist OSes. I’m sure that both quite some of the performance improvements Linux got over the years as well as some of the security improvements were pioneered elsewhere first.

By keeping the core requirements to do realistically doable, fun, FOSS work small enough to be understandable (port *one* assembler and linker, port *one* C compiler, don’t even bother wigth C++ or threads or SMP), and the amount of ressources *required* for that low enough (sure could do GCC but some targets do better with something like pcc at first), creativity *outside* of amd64/arm64 Linux/Windows/OSX monoculture can happen.

Oh FFS!

Posted Nov 24, 2024 22:05 UTC (Sun) by viro (subscriber, #7872) [Link]

Hadn't Linux early development been done with cross-builds on Minix, anyway? No idea how many patches to gcc had been Linux-specific in the first few years; H.J.Lu might be the right person to ask - IIRC, he'd done quite a bit of toolchain-related work...

Cross-builds are less of an issue these days - getting a kernel off the ground on bare metal may be an interesting exercise, but if you are going to do something interesting with it, the sane approach is to use KVM/qemu/whatnot at least for early development, so there's already a host infrastructure within easy reach...

Oh FFS!

Posted Nov 25, 2024 0:29 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (25 responses)

> Too bad when you’re a hobbyist OS

Well, then you just carry the patch yourself. If you're writing a freaking OS, then what's a big deal with one more patch?

Also your whole argument is disingenuous. If you want your OS, then you need a C++ compiler for it because both LLVM and gcc need it. And you for sure are not going to write a C++ compiler yourself. Adding Rust to the mix doesn't change the amount of work required.

> Now go back to when Torvalds wrote Linux. Do you think it could have gotten off the ground having to meet such insane requirements?

Indeed, back then Torvalds and other developers had to port binutils, X11, emacs, vim, and other programs. It was WAY more complicated than today.

These days, you just implement a bunch of interfaces, and a lot of infrastructure just falls in place. It's simply ridiculous how easy it is to develop operating systems now: https://gitlab.redox-os.org/redox-os/redox/

Oh FFS!

Posted Nov 25, 2024 1:48 UTC (Mon) by mirabilos (subscriber, #84359) [Link] (8 responses)

Don’t assume every hobbyist OS is “just Linux” though. The interesting experiments deviate, and they are where the undue burden is applied worst.

And no, without Rust, you absolutely do NOT need CFrustFrust. There’s many C compilers out there that don’t need it, and all the usual infrastructure as well. (For my hobbyist OS, not to be confused with the one I was referencing above, I got rid of GNU groff as last core component needing it by replacing a better alternative.)

Porting Emacs is harsh (due to its absolutely insane and unportable internal design), but nobody needs to port Emacs to have an (one) OS.

And, having worked my way from the bottom to the top because _my_ conclusion comes from here: you obviously have no idea of the burden that carrying local patches (as opposed to upstreaming them) is, nor that all the upstreams generally want patches upstreamed as well. Your FOSS experience is definitely not broad enough. Also, this is not the first time I see your name in… questionable replies; therefore, I ask you to please DO NOT INTERACT with my posts any further.

Oh FFS!

Posted Nov 25, 2024 5:38 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

> And no, without Rust, you absolutely do NOT need CFrustFrust. There’s many C compilers out there that don’t need it, and all the usual infrastructure as well.

So let me recap. You want the entire field of software development to bend over backwards to accommodate hypothetical hobbyist OSes that don't have support for C++ (and so no FireFox, Chrome, etc.).

You do realize how ridiculous it is? Especially given that porting LLVM/gcc to a new platform is a task doable within a month of work.

Oh FFS!

Posted Nov 25, 2024 6:17 UTC (Mon) by viro (subscriber, #7872) [Link] (6 responses)

For fairness sake, for e.g. prototyping a research project, Chromium or Firepox are hardly a priority - at about the same level of interest as ffmpeg et.al.

Said that, llvm requirements from the host are pretty minimal and unless the target is _really_ weird, getting a backend for it wouldn't be harder than comparable-quality pcc targeted to the same thing, so that really shouldn't be a big deal.

Getting decent target-specific optimizations can be interesting, of course, but then the same would go for pcc or gcc...

What kind of local llvm patch had that been? I'm really curious; the cost of keeping a local branch can, of course, be unpleasant, but that depends upon the area being modified. Could you (mirabilos, that is) drop it someplace public and post a link (along with commit sha1 of llvm version it's been against)?

Oh FFS!

Posted Nov 25, 2024 6:20 UTC (Mon) by mirabilos (subscriber, #84359) [Link] (4 responses)

@cyberax: what part of D.N.I. do you not understand?

@viro: not my code, and I’m not in the mood of wading through an unfamiliar codebase, probably still on svn of all things, to look for it, sorry.

Oh FFS!

Posted Nov 25, 2024 6:50 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Feel free to mute me if you don't want to see my posts.

Oh FFS!

Posted Nov 25, 2024 22:53 UTC (Mon) by mirabilos (subscriber, #84359) [Link] (1 responses)

There is no muting on LWN (for lynx and eMail).

What the fuck about DNI do you not understand? This is a basic consent thing.

Oh FFS!

Posted Nov 25, 2024 23:01 UTC (Mon) by corbet (editor, #1) [Link]

OK, cool it, please.

You posted a comment that can really only be seen as a troll. People fed the troll. You had no right to expect anything else, and have no right to tell others they cannot post on the site. Please just calm down and, perhaps, think a bit more before you post if you do not want people to disagree with you.

Oh FFS!

Posted Nov 25, 2024 7:22 UTC (Mon) by viro (subscriber, #7872) [Link]

llvm has moved to git 5 years ago, so presumably that patch is at least that old and I've enough software coproarchaeology on the kernel side...

Oh FFS!

Posted Nov 25, 2024 7:09 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> Said that, llvm requirements from the host are pretty minimal and unless the target is _really_ weird, getting a backend for it wouldn't be harder than comparable-quality pcc targeted to the same thing, so that really shouldn't be a big deal.

I was trying to think of a realistic example, and the only one I can think of, is that specialized C compiler (romcc) in Coreboot that used only registers for its memory because it works before the DRAM itself is initialized.

Oh FFS!

Posted Nov 25, 2024 8:54 UTC (Mon) by Wol (subscriber, #4433) [Link] (15 responses)

> Also your whole argument is disingenuous. If you want your OS, then you need a C++ compiler for it because both LLVM and gcc need it. And you for sure are not going to write a C++ compiler yourself. Adding Rust to the mix doesn't change the amount of work required.

WTF?

You're assuming a new OS springs out fully formed, like that greek goddess who sprang full grown out of her father's head when someone chopped it open (can't remember which legend, sorry).

If you're writing an OS from scratch, you start small! Personally, I'd probably use Forth as the most appropriate starting language, but ...

When you're a mouse, you don't worry about the elephants. Wait until you've grown a bit!

Don't get into circular arguments. Who cares if LLVM and gcc need a C++ compiler because C++ needs LLVM or gcc. Just don't use C++! What do you *NEED* it for? YOU DON'T.

Cheers,
Wol

Oh FFS!

Posted Nov 25, 2024 12:14 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

> Don't get into circular arguments. Who cares if LLVM and gcc need a C++ compiler because C++ needs LLVM or gcc. Just don't use C++! What do you *NEED* it for? YOU DON'T.

In the short term, you're cross-compiling anyway.

But it's a lot simpler to just port the parts of GCC/LLVM necessary for cross-compilation of C (including a very minimal libc) than it is to _also_ port the inftastructure neeed for C++ (and Rust) including their respective standard/runtime libraries.

Once you have the basics going, then you can go back and port a full-featured libc, then move on to the infrastructure needed for C++, Rust, and so forth as needed.

Oh FFS!

Posted Nov 25, 2024 18:04 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> But it's a lot simpler to just port the parts of GCC/LLVM necessary for cross-compilation of C (including a very minimal libc) than it is to _also_ port the inftastructure neeed for C++ (and Rust) including their respective standard/runtime libraries.

Oh, absolutely. Interestingly, adding Rust is _easier_ than C++. You don't need to worry about a lot of gnarly stuff like multiple inheritance, member pointers, and so on.

Oh FFS!

Posted Nov 30, 2024 14:35 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (1 responses)

What platform specifics are there for multiple inheritance and member pointers? ABI decisions? I'd expect most to just import the Itanium ABI for such things which would be minimal consideration for porting. But if one wants to describe their own ABI…yes, Rust probably has fewer decision points than C++.

Oh FFS!

Posted Nov 30, 2024 21:01 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

> What platform specifics are there for multiple inheritance and member pointers?

Virtual table layouts, virtual tables during object construction, and so on. For member pointers: the way you represent pointers to virtual functions (via offsets in a vtable). Also various small things, like allocating storage for the array length so that delete[] can properly run destructors.

Nothing too complicated, but still a fair bit of work. And I assume that you don't want to just re-use the existing ABI for some reason, because it equally applies to Rust as well as C++.

Oh FFS!

Posted Nov 25, 2024 17:48 UTC (Mon) by wittenberg (subscriber, #4473) [Link] (1 responses)

Athena sprung fully grown from Zeuss's head

Oh FFS!

Posted Nov 25, 2024 18:16 UTC (Mon) by Wol (subscriber, #4433) [Link]

Thanks.

Cheers,
Wol

Oh FFS!

Posted Nov 25, 2024 22:57 UTC (Mon) by mirabilos (subscriber, #84359) [Link] (8 responses)

(The offturning thing is that Rust, a language too immature to even be specified, is effectively required for even basic touching a computer soon, apparently.)

Yes, precisely, starting small… but at the same time, once the initial bootstrapping is done, stay self-hosting, because only by dogfooding you can even run into all the bugs, so all the development will be moved to the new OS as soon as possible.

Oh FFS!

Posted Nov 25, 2024 23:24 UTC (Mon) by Wol (subscriber, #4433) [Link] (5 responses)

> (The offturning thing is that Rust, a language too immature to even be specified, is effectively required for even basic touching a computer soon, apparently.)

And?

To quote Ecclesiastes, "there is nothing new under the sun" ...

That was true of Basic, C, PL/1, etc etc etc.

(The OS I cut my teeth on was originally written in FORTRAN, and slowly got transmogrified into PL/1, PLP, SPL, C, ...)

And hasn't Rust been specified for ages? Just because it's not ISO, or IEEE, or "insert your quango here" of the day ... you just say "this code needs edition 2018", and there's your spec.

Cheers,
Wol

Oh FFS!

Posted Nov 25, 2024 23:51 UTC (Mon) by pizza (subscriber, #46) [Link]

>And hasn't Rust been specified for ages?

The specification is "how [the latest version of] the official (and only) implementation does it"

Oh FFS!

Posted Nov 26, 2024 0:18 UTC (Tue) by mirabilos (subscriber, #84359) [Link] (2 responses)

AIUI it has not been specified other than “what rustc does”, which is a problem for the gccrs people.

And it wouldn’t be that bad if you could say edition 2018, and there’s an edition or two a decade.

Not multiple editions a day.

Oh FFS!

Posted Dec 13, 2024 19:51 UTC (Fri) by sammythesnake (guest, #17693) [Link] (1 responses)

They release new code pretty frequently, but in Rust land, an "Edition" is a specific thing[1] released very much less frequently[2] and which is stable and supported in all future versions of the compiler - no need to change any code (though the necessary changes can be made by automated handles

There are necessarily caveats to do with bugs and unavoidable backward incompatibility to handle security issues or whatever, but the only way to guarantee avoiding those is never release any new code at all...

[1] https://doc.rust-lang.org/edition-guide/editions/

[2] 2015, 2018, 2021 and 2024 so far, that's one every ~1100 days on average, so the orders of magnitude less often than you suggested.

Oh FFS!

Posted Dec 14, 2024 7:57 UTC (Sat) by sammythesnake (guest, #17693) [Link]

Sorry, fat-fingered edit there, the bracketed sentence "though the necessary changes can be made by automated handles" should have said "though the necessary changes _to support a new edition_ can be made by automated converters"

Oh FFS!

Posted Nov 26, 2024 11:12 UTC (Tue) by khim (subscriber, #9252) [Link]

> And hasn't Rust been specified for ages?

Nope. Rust reference says that in very red rectangle: Warning: This book is incomplete. Documenting everything takes a while. See the GitHub issues for what is not documented in this book.

Ferrocene have specification. That one is good enough to present to various bureaucrats, but it's very imprecise.

> you just say "this code needs edition 2018", and there's your spec.

Rust doesn't work like that. I can use “Rust edition 2015” and yet still use facilities that weren't available in year 2023, easily.

Rust edition is for breaking changes, not for supporting frozen-in-time toolchains.

Rust community stance for the demand to provide support for ancient compilers in the various crates was always: “you invent artificial limitations, you support artificial limitations… could fork old versions of old crates or do whatever you want, that's not our problem”.

Oh FFS!

Posted Nov 30, 2024 15:38 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (1 responses)

Someone go tell K&R that they should have specified C before using it for Unix back in 1968… Or anyone who used Python in some system-level required software before Jython/IronPython/etc. existed (or even today…what spec exists?) are committing similar offenses? Maybe so, but I argue that that's a way to also get nowhere as bootstrapping with waterfall development practices (as any such formal standardization turns out to be) sounds…painful and unproductive.

Oh FFS!

Posted Nov 30, 2024 20:19 UTC (Sat) by viro (subscriber, #7872) [Link]

Ugh... So many things wrong with that...

1) no C back in '68 (or Unix either, for that matter; they hadn't started that until '69, and back in early days B had been "we might want to use it someday" thing - C had started as an implementation language for one of the rewrites of B compiler several years later, with "looks like it can be used for a lot of things we wanted to use B for" coming shortly after that).

2) the _total_ size of v7 source ('79, with most of the early C changes already behind) is 3.4Mb (and not quite all of that C either - ~0.2Mb is assembler, and there's some data as well). Yes, by v7 time there'd already been quite a bit of C sources around (2BSD, for example), but nowhere near the size of Rust codebase these days. Impact of language changes does depend upon the amount of programs that need to be updated, so that comparison is more than slightly disingenuous.

3) while we are at it, "somebody go tell K & R" is somewhat in a poor taste - dmr died 13 years ago ;-/

Yes, grandparent posting by mirabilos reeks with advocacy, but that's not a reason to stoop down to the same.

Advocate: n. Pack animal, tends to produce a lot of noise, especially when two groups greet each other with projectile vomit and long loud screams. Can imitate speech better than parrots, but can't be used as pets due to guano problems.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds