Oh FFS!
Oh FFS!
Posted Nov 24, 2024 18:35 UTC (Sun) by jrtc27 (subscriber, #107748)In reply to: Oh FFS! by mirabilos
Parent article: NonStop discussion around adding Rust to Git
Posted Nov 24, 2024 19:13 UTC (Sun)
by viro (subscriber, #7872)
[Link] (6 responses)
Posted Nov 24, 2024 19:49 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Like, those Linux hippies?
Posted Nov 24, 2024 21:09 UTC (Sun)
by viro (subscriber, #7872)
[Link] (3 responses)
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.
Posted Nov 25, 2024 6:54 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
And hey, I do like a good flame once in a while.
Posted Nov 25, 2024 8:19 UTC (Mon)
by josh (subscriber, #17465)
[Link]
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".
Posted Nov 25, 2024 18:10 UTC (Mon)
by khim (subscriber, #9252)
[Link]
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.
Posted Nov 24, 2024 20:07 UTC (Sun)
by tux3 (subscriber, #101245)
[Link]
>Enter your comment text below. Before posting, though, please consider:
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.
Posted Nov 24, 2024 21:27 UTC (Sun)
by mirabilos (subscriber, #84359)
[Link] (27 responses)
“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.
Posted Nov 24, 2024 22:05 UTC (Sun)
by viro (subscriber, #7872)
[Link]
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...
Posted Nov 25, 2024 0:29 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (25 responses)
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/
Posted Nov 25, 2024 1:48 UTC (Mon)
by mirabilos (subscriber, #84359)
[Link] (8 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. (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.
Posted Nov 25, 2024 5:38 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
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.
Posted Nov 25, 2024 6:17 UTC (Mon)
by viro (subscriber, #7872)
[Link] (6 responses)
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)?
Posted Nov 25, 2024 6:20 UTC (Mon)
by mirabilos (subscriber, #84359)
[Link] (4 responses)
@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.
Posted Nov 25, 2024 6:50 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Nov 25, 2024 22:53 UTC (Mon)
by mirabilos (subscriber, #84359)
[Link] (1 responses)
What the fuck about DNI do you not understand? This is a basic consent thing.
Posted Nov 25, 2024 23:01 UTC (Mon)
by corbet (editor, #1)
[Link]
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.
Posted Nov 25, 2024 7:22 UTC (Mon)
by viro (subscriber, #7872)
[Link]
Posted Nov 25, 2024 7:09 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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.
Posted Nov 25, 2024 8:54 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (15 responses)
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,
Posted Nov 25, 2024 12:14 UTC (Mon)
by pizza (subscriber, #46)
[Link] (3 responses)
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.
Posted Nov 25, 2024 18:04 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
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.
Posted Nov 30, 2024 14:35 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Nov 30, 2024 21:01 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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++.
Posted Nov 25, 2024 17:48 UTC (Mon)
by wittenberg (subscriber, #4473)
[Link] (1 responses)
Posted Nov 25, 2024 22:57 UTC (Mon)
by mirabilos (subscriber, #84359)
[Link] (8 responses)
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.
Posted Nov 25, 2024 23:24 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (5 responses)
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,
Posted Nov 25, 2024 23:51 UTC (Mon)
by pizza (subscriber, #46)
[Link]
The specification is "how [the latest version of] the official (and only) implementation does it"
Posted Nov 26, 2024 0:18 UTC (Tue)
by mirabilos (subscriber, #84359)
[Link] (2 responses)
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.
Posted Dec 13, 2024 19:51 UTC (Fri)
by sammythesnake (guest, #17693)
[Link] (1 responses)
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.
Posted Dec 14, 2024 7:57 UTC (Sat)
by sammythesnake (guest, #17693)
[Link]
Posted Nov 26, 2024 11:12 UTC (Tue)
by khim (subscriber, #9252)
[Link]
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. 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”.
Posted Nov 30, 2024 15:38 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Nov 30, 2024 20:19 UTC (Sat)
by viro (subscriber, #7872)
[Link]
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.
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
> 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!
Apropos the local Victorian Sufi Buddha
>
> - Is your comment polite, respectful, and informative?
> - Are you saying something new that extends the conversation?
> - Have you provided a useful subject line?
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
OK, cool it, please.
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
Wol
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
Wol
Oh FFS!
Oh FFS!
Oh FFS!
Oh FFS!
> And hasn't Rust been specified for ages?
Oh FFS!
Oh FFS!
Oh FFS!