Open Source Software Community - it's about ethics in Code of Conducts

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
We just need to take the best features of each. The pointer support from C, the readability of Perl, the cross-platform support of Rust, the speed of Python, the privacy of Go, the simplicity of C++, the wide adoption of Ruby, the autism of Lisp.
why aren't we including the down-to-earth practicality of haskell, the modern conveniences of pascal, the standard library of lua, the incredibly lightweight runtimes of java and c#, the higher-order data structure processing ability of old fortran, and the flexibility and terseness of cobol
When Emacs switches to Guile
one day you will be able to run guilemacs... on your hurd 1.0 box
 
why aren't we including the down-to-earth practicality of haskell, the modern conveniences of pascal, the standard library of lua, the incredibly lightweight runtimes of java and c#, the higher-order data structure processing ability of old fortran, and the flexibility and terseness of cobol

one day you will be able to run guilemacs... on your hurd 1.0 box
While browsing on Xanadu, talking to CyC.
 
Fossil is almost perfect but SQLite chokes pretty badly on binary files and it's lack of pull/push request support (Even making patches is pretty wonky) are two huge bullets in an otherwise excellent product.
Use DARCS (haskell based) like I mentioned as a shitpost before... Sadly, the spiritual successor pijul is written in rust by a troon.
I hate fucking RCS systems.
Git is forced upon most people
Mercuiral is run by a troon
Fossil depends on SQLite (and I think suffer from creep like systemd)
Darcs is good at times but lmao 15 year unfixed urgent bug.
Pijul is written in rust.

Back to the CVS days we go.
This bug in the darcs-2 conflictor implementation is practically
unfixable, like many others, due to the extreme complexity and
obscurity of the code.
 
why aren't we including the down-to-earth practicality of haskell, the modern conveniences of pascal, the standard library of lua, the incredibly lightweight runtimes of java and c#, the higher-order data structure processing ability of old fortran, and the flexibility and terseness of cobol
Can anyone explain why I would ever even try to write in anything other than posix shell? It has everything you will ever need. if statements, case statements, while loops, (god forsaken) for loops, and until loops, functions. If you want more than that you are trying too hard.
 
Can anyone explain why I would ever even try to write in anything other than posix shell? It has everything you will ever need. if statements, case statements, while loops, (god forsaken) for loops, and until loops, functions. If you want more than that you are trying too hard.
it can't really do arrays or numbers but that's what you use sed and dc for
 
now those are TRUE vaporware
because at least bootable hurd images exist and there have been actual builds of guile emacs in the past
I think Hurd can be taken out of the Vaporware category and placed more in the Duke Nukem Forever category (which, ironically, reached 1.0 status before Hurd did). Now that I think about it, though, they did eventually open source one transcompiled copy of Xanadu (Smalltalk -> C++). But hey, at least CyC is still total fucking vaporware (and always will be).
 
Hear me out. What is needed is another new programming language.
Let's call it STAINLESS and have it be basically C but with one tiny change, and it's either fully backwards compatible with c code or c code can be perfectly converted to STAINLESS using automated tools

What would be the smallest changes to C where the language is pretty much the same but some key issues are resolved? Maybe changing how pointers are defined, such as the pointer always having the type and string length defined at the beginning of the memory location so anything that accesses it can only access it if they see it as the right type, and they can't access anything beyond what is defined?
 
Last edited:

Another Lunduke that just feels dishonest.. He talks about how openSUSE is disabling bcachefs, and tries to make the developer just seem like some "opinionated" guy. He calls the Linux kernel maintains "penguin nuns."

Anyone whose actually read the mailing list e-mails know this guy was a piece of work, submitting features during code freezes and being horribly uncooperative when it came to basic code policies. At around 5:50, Lunduke claims all the other developers, including Linus himself, have pushed massive breaking changes late in the development cycle. I know this happened years ago, but .. has this happened since Torvalds had his whole coming to Jesus moment a while back? Lunduke claims the removal of bcachefs has nothing to do with anything political, but just that the kernel maintainers don't like the guy. But then Lunduke doesn't go over any of the actual e-mails or evidence; just states his opinion and hand waves it away.
Lunduke is a retard. Like you said, anyone can read the mailing lists. Kent Overstreet has created problems before and never learned his lesson. Lunduke's story is stupid, as usual. "For no reason" the evil kernel developers got angry and even though they had already incorporated bcachefs to the kernel, just to be meanies they decided to kick it back out, again, for no reason.

Kent was a fucking retard who was trying to merge features in an RC, and he had done it (and been warned) multiple times. There are rules to kernel contribution. If you can't follow them, you are going to piss off a lot of people. He pissed off one too many people one too many times and now he's exiled. Unless some genius comes along and decides to be the bcachefs maintainer, its days are numbered and the days are counting down until it will be chopped out of the kernel forever.

Kent is free to develop out of tree, of course, but without mainline support, it's just going to be another patchset... I can't say I feel bad for the guy.
 
Let's call it STAINLESS and have it be basically C but with one tiny change, and it's either fully backwards compatible with c code or c code can be perfectly converted to STAINLESS using automated tools

What would be the smallest changes to C where the language is pretty much the same but some key issues are resolved? Maybe changing how pointers are defined, such as the pointer always having the type and string length defined at the beginning of the memory location so anything that accesses it can only access it if they see it as the right type, and they can't access anything beyond what is defined?
Smallest change to the C language ? Zero changes.
I say this with absolute confidence because it has already been done, several times.


There are prototypes of such extensions to automatically add this in C-compilers
and protect against memory errors such as buffer overflows and use after free.

I recall a project that built the entire userspace and the kernel for one of the BSDs with this as a prototype. That project also built all of linux userland with that support but I vaguely recall that there was some aprticular thing in the kernel that prevented them from also building the linux kernel with it.

There were several similar projects over the years. I just recall this one in particular as if managed to built entire userland and also in one case the entire kernel as well.
That was just normal C, no need to invent a completely new language.

Problem was performance. I could well remember completely wrong but I think they took in the order of 30-50% hit in performance. Some of the whitepapers discussed possible approaches in future work to make the impact less severe. Haven;t followed up or tracked what ended up happening. As is common in research they probably did not get funding for the next steps so the project just died, probably.

But still, there were several different approaches that made C safe but they al suffered from a hit to performance. Some of them even demonstrated real systems fully compiled this way.
 
Last edited:
Kent is free to develop out of tree, of course, but without mainline support, it's just going to be another patchset... I can't say I feel bad for the guy.

I did and still do apply patchsets to my kernel for various stuff that doesn't make it into mainline for (often good) reasons and I can only advise people to be at least open to it but that said, I'd never take a patchset of that guy. Something like a filesystem needs to be 100% reliable and predictable. That guy has shown such a volatile disregard and inability to listen to critque, taking his out-of-tree patches is an accident waiting to happen. I can already see the WONTFIX because "it's better that way and also you used it wrong to begin with". No thanks, IMO.
 
guy will rewrite all the rustarded code in c (or maybe something actually better (simpler) than c?) again
this plan is scheduled to go into full force in 2029 when it is projected that 93% of the packages in the debian archives will just be various shitty rust crates for printing ansi terminal escapes to stdout
Just you wait my nigger, for when the holy day comes we will all bask in the wonders of crisp, clean, trany-free Guile GNU/git (read: nugget). Join me as we prepare to invoke the holy ritual by handwriting the entire GCC stack in Winjeet blood, and WITNESS the evocation of the holy Hurd!
 
the language is pretty much the same but some key issues are resolved
The C language design itself is one of the biggest key issues. The complexity of the pre-processor, the complexity of the post-pre-processor parsing, et cetera. The C language has decades of hacking around "key issues", and that is itself one of the key issues today.
 
I did and still do apply patchsets to my kernel for various stuff that doesn't make it into mainline for (often good) reasons and I can only advise people to be at least open to it but that said, I'd never take a patchset of that guy. Something like a filesystem needs to be 100% reliable and predictable. That guy has shown such a volatile disregard and inability to listen to critque, taking his out-of-tree patches is an accident waiting to happen. I can already see the WONTFIX because "it's better that way and also you used it wrong to begin with". No thanks, IMO.
Ironically, when asked about his irregular behavior, he says that he is breaking the rules to get REAL FIXES out to REAL PEOPLE. Maybe if he moved a hair slower, he wouldn't have had these problems in the first place. Now it's going to be largely academic because he's been exiled to Kent-land, population one. Now he can piss and shit all over his own git repo and do whatever he wants. Anyone with enough motivation can clone his repo and run bcachefs, but I think that's going to be a shrinking crowd. Too bad, because Linux could badly use something as decent as ZFS without the licensing incompatibility.
 
The C language design itself is one of the biggest key issues. The complexity of the pre-processor, the complexity of the post-pre-processor parsing, et cetera. The C language has decades of hacking around "key issues", and that is itself one of the key issues today.
The complexity does allow for performance improvements, at the cost of the developer having to know what they fuck they are doing.

How about a programming language that is a little bit more complicated and memory unsafe, but allows for even faster code when written correctly?
 
How about a programming language that is a little bit more complicated and memory unsafe, but allows for even faster code when written correctly?
"A little bit more complicated" is basically C++. The problem is that you don't want more complicated than C, syntactically speaking. C is already much more complex than any of its competitors in terms of implementation details, save C++. Rust is less complex than C despite providing "more power". But you correctly perceive that there's a market for "C but a bit less complex". Most go "C but a bit less complex and a bit more high level" (ie. Rust, Jai, Zig, Nim, whatever), but very few go "C but a bit less complex and a bit more low level".
 
expr entered the chat
fuck im dumb
The C language design itself is one of the biggest key issues. The complexity of the pre-processor, the complexity of the post-pre-processor parsing, et cetera. The C language has decades of hacking around "key issues", and that is itself one of the key issues today.
step 1 of making c good is probably giving it a lisp-like syntax and a macro system at least as powerful as scheme's syntax-rules. the addition of syntax-rules would be completely free during runtime and give you a bunch of nice features, which is very fitting for any c-like language
Rust is less complex than C despite providing "more power".
ehhh i'd say rust is more complex than raw c99 but less complex than gnu c23 or something like that
if rust was simple it would be much easier to bootstrap than it is
 
Back
Top Bottom