|
|
Subscribe / Log in / New account

Glad I am not using FreeBSD

Glad I am not using FreeBSD

Posted Aug 20, 2024 10:53 UTC (Tue) by khim (subscriber, #9252)
In reply to: Glad I am not using FreeBSD by taladar
Parent article: FreeBSD considers Rust in the base system

I think you are missing a lot of context here, that's why the overreaction.

> Also, why would anyone want to reimplement some ancient CVS related tool? Presumably that is still in some way important to FreeBSD?

I'll correct for you: Also, why would anyone want to reimplement some ancient CVS related tool central tool which is used to manage FreeBSD code?

Does that question even need answers?

> Presumably that is still in some way important to FreeBSD?

From the FreeBSD wiki: FreeBSD uses a mixture of CVS and Perforce for managing the various source trees and projects; CVS (extended with cvsup) is the "authoritative" revision control system, and contains four complete and independent repositories (src, ports, projects, doc), but its limitations regarding heavily branched independent development are significant (emphasis mine).

Asking to reimplement pretty important tool that's written, for some unfathomable reason, in a Modula-3, of all things, sounds like a pretty reasonable request.

There are plenty of people who are seeking projects to rewrite in Rust (as learning excercise), asking one of them to rewrite CVSup before doing more commitment would be a good idea. Maybe it's possible to even convince some company to give funds for such excercise to someone.


to post comments

Glad I am not using FreeBSD

Posted Aug 20, 2024 11:13 UTC (Tue) by Vorpal (guest, #136011) [Link]

> I'll correct for you: Also, why would anyone want to reimplement some ancient CVS related tool central tool which is used to manage FreeBSD code?
>
> Does that question even need answers?

It does raise the question as to why FreeBSD would still be relying on CVS in this day and age...

That said Modula-3 seems to be a saner language than C or C++ (I say this as a professional C++ developer who have worked in safety critical hard real-time for over a decade, and am now a huge fan of Rust).

Looking at the examples on Wikipedia for Modula-3 it reminds me of a mix of Pascal/Ada with the upper case of Fortran. I prefer something a bit less verbose and more functional personally, but it sounds like it is at least somewhat memory safe.

At the time it was probably a sensible choice (the other options would be been Ada or a scripting language I guess?). Now it will suffer from the lack of an ecosystem, which means fewer people who understand the code, and less available libraries (meaning you have to write everything yourself).

Glad I am not using FreeBSD

Posted Aug 20, 2024 13:37 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (1 responses)

I think there are a few sensible precautions before anybody took on the considerable work of rewriting CVSup in Rust

- Is there "buy in"? Do the users of CVSup want Rust CVSup, or does it just go in the pile of "Tasks we set for Rust developers as a prank" when you're finished?

- Is the present behaviour of CVSup well characterised, documented, maybe there are even unit tests so that we can tell whether our Rust CVSup is in fact a working replacement ?

- Is there something CVSup doesn't do that a Rust CVSup could fix? Or equally something it does do that it shouldn't?

My guess is that in fact these are merely "top bants" and in practice there is no actual interest in a Rust CVSup so this exercise would be futile.

Notice the linked Perforce page just tells you FreeBSD hasn't used Perforce for years. This is legacy documentation, most of FreeBSD's documentation can be described as "Somebody wrote this, nobody is in charge of making sure it's still correct and we don't keep records of what it's about or why it was written. Good luck". Maybe CVSUp is exciting new software just introduced, maybe it is being replaced with a C equivalent for platform compat reasons. Maybe both those stories are long obsolete.

Glad I am not using FreeBSD

Posted Aug 21, 2024 17:34 UTC (Wed) by mrugiero (guest, #153040) [Link]

You need to no further from "is it likely that the first thing included in base done in <language> will be one of the most core ones?" to know it is just meant as a disincentive. It's just meant to raise the barrier of entry, quite the opposite to what Rust is about. That is, condescending gatekeeping.

Glad I am not using FreeBSD

Posted Aug 20, 2024 14:14 UTC (Tue) by HJVT (guest, #172982) [Link] (2 responses)

> Asking to reimplement pretty important tool that's written, for some unfathomable reason, in a Modula-3, of all things, sounds like a pretty reasonable request.

That's not the request though. The request is for someone interested in getting language A adopted in base to reimplement a tool written in an obscure language B, that has not seen continued development in nearly 15 years, nor has ever seen significant adoption.
So it would seem absolutely fair to assume that barely anybody knows the language B, which means the request is actually to learn this language to a fairly competent level. Which somehow will demonstrate that the value of adopting the language A?

Glad I am not using FreeBSD

Posted Aug 20, 2024 14:25 UTC (Tue) by khim (subscriber, #9252) [Link]

Have you actually tried to rewrite something? I mean: ever in your life?

Sure, you need to know two languages, but most of the time you have to be an expert only in target language, you need to have only very rough understanding of source language.

Otherwise these projects that replace COBOL with Java would have been entirely impossible (and in reality only half of them fail).

Glad I am not using FreeBSD

Posted Aug 21, 2024 17:38 UTC (Wed) by mrugiero (guest, #153040) [Link]

Playing Devil's advocate, the underlying message must be something along the lines of "we don't know if Rust will be around in 10 years from now, let's see you deal with our previous mistakes of early adoption so you know what we'd be signing up for in case Rust becomes an old obscure language as well". But that said, that argument is already old IMO. If there is ONE thing where "all the cool kids do it" is actually a fair argument is for chances of it being around in 10 years. When "all the cool kids do it" you create tons of future legacy code that someone will have to deal with, which means someone will maintain a toolchain for it.

Glad I am not using FreeBSD

Posted Aug 20, 2024 14:39 UTC (Tue) by a12l (guest, #144384) [Link] (4 responses)

> From the FreeBSD wiki: FreeBSD uses a mixture of CVS and Perforce for managing the various source trees and projects; CVS (extended with cvsup) is the "authoritative" revision control system, and contains four complete and independent repositories (src, ports, projects, doc), but its limitations regarding heavily branched independent development are significant (emphasis mine).

That article is there for historical reasons (as noted in the banner at the top), and not actually relevant nowadays. FreeBSD has migrated from CVS --> SVN --> Git, the latest migration done around 2020.

Glad I am not using FreeBSD

Posted Aug 20, 2024 14:44 UTC (Tue) by khim (subscriber, #9252) [Link] (3 responses)

If that's true then I have to agree with taladar and repeat after him: I am so glad I am not using FreeBSD anywhere.

Glad I am not using FreeBSD

Posted Aug 20, 2024 15:01 UTC (Tue) by shawn.webb (subscriber, #118686) [Link] (2 responses)

What's wrong with FreeBSD using git? How do you stay away from any project that uses git?

Glad I am not using FreeBSD

Posted Aug 20, 2024 15:23 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

Nothing is wrong with using Git. But asking for a rewrite of a tool that you are no longer using is just dishonest.

Glad I am not using FreeBSD

Posted Aug 21, 2024 7:16 UTC (Wed) by viro (subscriber, #7872) [Link]

Modula 3 toolchain had been a recurring nightmare for maintainers. Having a critical (at the time) tool written in that was a painful mistake; the real solution was to switch away from CVS and be done with both cvsup and modula 3 support. An intermediate was "fuck that m3 shite, let's rewrite the parts of cvsup we really need in C, so the entire system wouldn't be a hostage of that horror" (csup). I suspect that phk point is not so much a literal requirement for rust-in-core-system advocates as a reminder of the last time when somebody decided that "it's such a nice language" was a sufficient argument for making the system depend on unstable toolchain.

They paid _hard_ for that mistake with m3. Granted, rust toolchain is nowhere near that horror (look it up yourself - it really could be used as an object lesson in how not to do language toolchains), but cvsup story must've left very painful scars.

Glad I am not using FreeBSD

Posted Aug 21, 2024 8:06 UTC (Wed) by taladar (subscriber, #68407) [Link] (10 responses)

Personally I wouldn't use any project that still uses CVS. Granted, CVS is slightly better than Subversion but it is still an extremely bad version control system compared to even the less popular modern ones.

Glad I am not using FreeBSD

Posted Aug 21, 2024 8:46 UTC (Wed) by chris_se (subscriber, #99706) [Link] (9 responses)

> CVS is slightly better than Subversion

Huh? Personally, I found SVN to be a huge step up from CVS. Back in the day (pre git) I switched over to it from CVS before even SVN 1.0, because it was so much better in my eyes. Granted, I've been using git exclusively for everything for a long time now, and I don't want to look back. And don't get me wrong: I do have lots of criticisms for SVN - but I'm utterly baffled by the statement that CVS is better than SVN. Could you elaborate what CVS does better than SVN in your eyes?

Glad I am not using FreeBSD

Posted Aug 21, 2024 10:46 UTC (Wed) by paulj (subscriber, #341) [Link] (4 responses)

Subversion was not very stable, least over the timeframe where it was the only serious alternative to CVS. The easier to setup backend (I forgot the name) in particular had some corruption bugs. My vague memory is that the by the time it was reliable enough to trust, there were other and better alternatives (distributed SCMs that is).

Glad I am not using FreeBSD

Posted Aug 21, 2024 15:16 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

The initial backend used BerkeleyDB, and it sometimes became "wedged", requiring manual intervention. They fairly quickly followed it by FSFS (filesystem over filesystem) that used immutable files to represent revisions. This backend was (and still is) rock-solid. That was still years before git.

Glad I am not using FreeBSD

Posted Aug 21, 2024 15:50 UTC (Wed) by paulj (subscriber, #341) [Link] (2 responses)

Yeah, BDB.

Googling suggests FSFS came out in SVN 1.1, in 2004-09-29. Anyone burned by the BDB implementation in SVN was, obviously, going to wait a while to see how FSFS panned out before jumping in. At that point, the DSCM movement was already underway, with monotone and Darcs (evolving from Arch) in existence - giving further pause to anyone considering switching SCM to see how things would pan out. Less than 8 months later we got git (and mercurial soon after).

There was a window in 2002 to '03 or so when SVN looked like maybe it was the answer to "what should replace CVS?". But it was buggy. By the time you could FSFS was available and trustworthy, it was too late.

Glad I am not using FreeBSD

Posted Aug 22, 2024 7:18 UTC (Thu) by chris_se (subscriber, #99706) [Link] (1 responses)

I apparently got really lucky. I remember using SVN quite a lot in the early 2000's (starting ~2001 or so), and while the FSFS transition was nice because it was a lot faster than BDB, I never really had issues with the BDB backend (at least as far as I can recall 20 years after the fact).

Additionally, while git was started in 2005, I remember looking at it in early 2006 (or so) and was immediately put off, because the user interface back then was atrocious (IMHO). I don't remember exactly when, but I only looked at git again somewhere in 2008 or 2009, when the user interface had already gotten much better.

So I had at least 7 years of mostly good experiences with SVN back then. Now of course, in hindsight there are a lot of shortcomings in its design, and from the lens of today I'd probably characterize my experience working with SVN back then very differently. But at the time I didn't have that much to complain about. I definitely wouldn't want to go back from git.

I can definitely see the perspective you shared as to why you didn't seriously consider SVN as a successor to CVS for historic reasons. But I'm still confused as to the statement I replied to initially that CVS is slightly better than SVN (present tense). It might have been in 2003 when FSFS didn't yet exist (due to bugs in BDB), but nowadays?

Glad I am not using FreeBSD

Posted Aug 22, 2024 11:42 UTC (Thu) by anselm (subscriber, #2796) [Link]

But I'm still confused as to the statement I replied to initially that CVS is slightly better than SVN (present tense).

AFAIR the main advantage of SVN compared to CVS was that SVN would let you rename directories.

I personally used SVN for a bit but then moved over to Arch and eventually to Mercurial (which IMHO is way underrated). At work these days we're using Git, but for me, that needs Magit to make it halfway bearable.

Glad I am not using FreeBSD

Posted Aug 22, 2024 8:04 UTC (Thu) by taladar (subscriber, #68407) [Link] (3 responses)

CVS repos are much easier to import into something modern like Git because Subversion did that stupid thing where it tried to make everything a path and so you can end up with multiple revisions for tags and projects using their own concepts that do not exactly match branches or tags based on that low level filesystem-path abstraction.

Glad I am not using FreeBSD

Posted Aug 26, 2024 7:49 UTC (Mon) by marcH (subscriber, #57642) [Link] (2 responses)

Yes: Subversion "quietly" got rid of... tags and branches! Quite extraordinary for a version control system. Even more extraordinary: it took me a year or two to realize it and describe it here:

https://en.wikipedia.org/wiki/Apache_Subversion#Subversio...

Glad I am not using FreeBSD

Posted Aug 26, 2024 9:30 UTC (Mon) by kleptog (subscriber, #1183) [Link] (1 responses)

Yeah, SVN made it very easy to branch (just copy, simple right?) but merging was a clusterf*ck. At one point they added "merge tracking" to keep track which revisions had been merged from where but it never worked well for me,

I think it was Linus in a discussion about Git noting that the one thing a revision control system really needed to be good at was merging and SVN failed that miserably.

git-svn was the only thing that made it usable for me. Then I could have local branches without dealing with the server.

Glad I am not using FreeBSD

Posted Aug 26, 2024 15:13 UTC (Mon) by marcH (subscriber, #57642) [Link]

I learned git with... git-svn the first time: purely because I was so sick of SVN (and not just the lack of branches).


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