apam wrote to jimmylogan <=-

I think Linux is GREAT for getting use out of old hardware
that might otherwise be unusable...

I would say linux used to be good, but in my opinion it's become a bit
of a mess in recent years.

Interesting - there are different distros - unless you just don't
want to, try MINT or DEBIAN or something else.



... This tagline is property of Oaks Correctional Facility
--- MultiMail/Mac v0.52
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

Interesting - there are different distros - unless you just don't
want to, try MINT or DEBIAN or something else.

I have tried MINT and DEBIAN, i last used debian trixie on my desktops
and firefox would continually crash. I don't know why. I do keep trying different distros though to see if things change, and I'm currently using fedora 43 kde spin - it seems to be working ok even using wayland.

In my experience though, different distros just have their own set of
problems. And with fedora taking AI contributions... i don't have much
faith that it wont run into issues soon.

FreeBSD doesn't do as much, and I suppose that could be seen as some
deficiency (ie, I can't use optimus on my laptop) but what it does do it
does well.

I guess I'm just disappointed, after 25+ years of using Linux I thought
things would have gotten a lot better, and yes, in many ways they have -
but i think all the improvements have brought so much extra complexity
that theres so much that can and does go wrong.

And so much of this complexity and newness just seems to me to be new for
the sake of being new. Ubuntu using rust coreutils for example ... why?
The existing core utils have been worked on for many years and work well,
but rust is the new shiny and we have to port to that to be safe - so
there's now a bunch of issues with compatibility with new core utils,
which will be worked out eventually, but for what?

Now I am all for people working on what interests them, and I suppose
that's what is happening. If ubuntu developers feel that making rust core
utils is a good thing, then it's their distro and they can do what they
like.

I want a computer that works well, it just seems to be such a moving
target and frustrates me.

Andrew


--- envy/0.1-8c9ebf2
* Origin: Quinn - Random Things - bbs.quinnos.com:2323 (21:3/197)

I have tried MINT and DEBIAN, i last used debian trixie on my desktops
and firefox would continually crash. I don't know why. I do keep trying different distros though to see if things change, and I'm currently using fedora 43 kde spin - it seems to be working ok even using wayland.

Currently using trixie. I keep firefox updated and it does not crash.
That said, there are some websites that refuse to work with it, but I
suspect that is more site specific and not necessarily the browser. Those usually work fine with chromium.

Despite what some claim, I have found that the WM you use makes a
difference. I had one program, audacity, that was not working well under
LXQT but works just fine with IceWM.

FreeBSD doesn't do as much, and I suppose that could be seen as some deficiency (ie, I can't use optimus on my laptop) but what it does do it
does well.

I tried Free or OpenBSD a time or two. That was probably back 10+ years
ago and, at the time, it seemed to have more hardware (and browser) issues
than debian did.

I guess I'm just disappointed, after 25+ years of using Linux I thought things would have gotten a lot better, and yes, in many ways they have -
but i think all the improvements have brought so much extra complexity
that theres so much that can and does go wrong.

IMHO, the more "desktop user" compatable you make an OS, the more likely it
is to wind up bloated like Windows. IMHO, a large part of that is related
to how most web pages don't follow a standard, which means the browsers are seriously bloated and memory hungry. I have few problems so long as I
don't have a browser open.

And so much of this complexity and newness just seems to me to be new for
the sake of being new. Ubuntu using rust coreutils for example ... why?
The existing core utils have been worked on for many years and work well,
but rust is the new shiny and we have to port to that to be safe - so
there's now a bunch of issues with compatibility with new core utils,
which will be worked out eventually, but for what?

Ubuntu is something I avoid. I used to use it but had it twice completely break the system after following the directions for an apt full-upgrade. Ditched it and installed its predecessor, debian, and have had no issues
with apt since.

Unfortunately, some of the duhcisions they make do find their way back into debian. Hopefully, this coreutils change won't.

I want a computer that works well, it just seems to be such a moving
target and frustrates me.

Indeed.


* SLMR 2.1a * So easy, a child could do it. Child sold separately.
--- SBBSecho 3.28-Linux
* Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (21:1/175)

apam wrote to jimmylogan <=-

I want a computer that works well, it just seems to be such a moving target and frustrates me.

I get it... That's why I'm fine with MacOS overall... I only use
Linux on 'older' equipment.


... If this were an actual tagline, it would be funny.
--- MultiMail/Mac v0.52
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

On 01 Nov 2025 at 05:43a, apam pondered and said...

And so much of this complexity and newness just seems to me to be new for the sake of being new. Ubuntu using rust coreutils for example ... why? The existing core utils have been worked on for many years and work well, but rust is the new shiny and we have to port to that to be safe - so there's now a bunch of issues with compatibility with new core utils, which will be worked out eventually, but for what?

I can speak to this a little bit. Two reasons that I see
initially include a) code quality and maintainability issues
with GNU coreutils, and b) the GNU license. uutils is much
better code generally (unit tests!!), and certainly easier to
maintain, the project uses modern development practices with
respect to review, CI, and so on. And the MIT license makes
it much easier to integrate with other projects.

The issue with compatibility is real, but I would argue that
in some ways this is good: there are already alternative user
space implementations of the POSIX and Unix utilities (the
BSDs, System V, various commercial Unixes that still exist,
and so on). Having diversity in this area forces downstream
projects to be a bit cleaner and more disciplined.

As for ubuntu switching to uutils? Meh, I'm ambivalent, but
that's largely because I think that Canonical is run by a loon.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 24 Nov 2025 at 02:54a, tenser pondered and said...

On 01 Nov 2025 at 05:43a, apam pondered and said...

And so much of this complexity and newness just seems to me to be new the sake of being new. Ubuntu using rust coreutils for example ... wh The existing core utils have been worked on for many years and work w but rust is the new shiny and we have to port to that to be safe - so there's now a bunch of issues with compatibility with new core utils, which will be worked out eventually, but for what?

I can speak to this a little bit. Two reasons that I see
initially include a) code quality and maintainability issues
with GNU coreutils, and b) the GNU license. uutils is much
better code generally (unit tests!!), and certainly easier to
maintain, the project uses modern development practices with
respect to review, CI, and so on. And the MIT license makes
it much easier to integrate with other projects.

The issue with compatibility is real, but I would argue that
in some ways this is good: there are already alternative user
space implementations of the POSIX and Unix utilities (the
BSDs, System V, various commercial Unixes that still exist,
and so on). Having diversity in this area forces downstream
projects to be a bit cleaner and more disciplined.

As for ubuntu switching to uutils? Meh, I'm ambivalent, but
that's largely because I think that Canonical is run by a loon.

I think in some part, the move to Rust is due to zealots who want to control software, or at least, have some more social control. I don't trust evangelists, and that is with good reason. Perhaps it is also in part to undermine software freedom?

... A book in the hand is worth two on the shelf!

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Re: macOS 26
By: boraxman to tenser on Sun Nov 30 2025 12:51 am

I think in some part, the move to Rust is due to zealots who want to control software, or at least, have some more social control. I don't trust evangelists, and that is with good reason. Perhaps it is also in part to undermine software freedom?

The only reason I've heard of people moving to Rust is that it has been designed to help prevent some common programming pitfals that lead to bugs in software (such as more protection against memory leaks, etc.). It seems reasonable to me.. Even the best & most careful programmers with C & C++ can make mistakes sometimes that lead to software bugs.

Nightfox
--- SBBSecho 3.31-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

On 30 Nov 2025 at 12:51a, boraxman pondered and said...

I can speak to this a little bit. Two reasons that I see
initially include a) code quality and maintainability issues
with GNU coreutils, and b) the GNU license. uutils is much
better code generally (unit tests!!), and certainly easier to maintain, the project uses modern development practices with
respect to review, CI, and so on. And the MIT license makes
it much easier to integrate with other projects.

The issue with compatibility is real, but I would argue that
in some ways this is good: there are already alternative user
space implementations of the POSIX and Unix utilities (the
BSDs, System V, various commercial Unixes that still exist,
and so on). Having diversity in this area forces downstream
projects to be a bit cleaner and more disciplined.

As for ubuntu switching to uutils? Meh, I'm ambivalent, but
that's largely because I think that Canonical is run by a loon.

I think in some part, the move to Rust is due to zealots who want to control software, or at least, have some more social control. I don't trust evangelists, and that is with good reason. Perhaps it is also in part to undermine software freedom?

Do you have any evidence to support this view point?

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 29 Nov 2025 at 09:17a, Nightfox pondered and said...

The only reason I've heard of people moving to Rust is that it has been designed to help prevent some common programming pitfals that lead to
bugs in software (such as more protection against memory leaks, etc.).
It seems reasonable to me.. Even the best & most careful programmers
with C & C++ can make mistakes sometimes that lead to software bugs.

Rust is, frankly, a better language than either C or C++, but
with good reason: it had 35 years of C and 30 years of C++
history to learn from when it was designed. Plus it could also
draw on lessons learned from research in the wider PL community
over those decades. But it's easy to do better when you've got
so much data you can learn from.

Rust is not perfect, and has made some very bad design decisions,
in my opinion: the `async` stuff was not fully baked and is full
of footguns, and the recent chatter about not poisoning mutexes
by default anymore is misguided and just plain wrong. The learning
curve is notoriously steep. But at its core, Rust helps programmers
write correct, performant, programs faster, and to do so across a
wide variety of domains. That said, it's just another tool in the
box, and it's not the only language a programmer should know.

These conspiracy-theories about control, evangelism, attacks on
software freedom, etc, are just uninformed nonsense.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Re: macOS 26
By: tenser to Nightfox on Thu Dec 04 2025 07:20 am

Rust is, frankly, a better language than either C or C++, but with good reason: it had 35 years of C and 30 years of C++ history to learn from when it was designed. Plus it could also draw on lessons learned from research in the wider PL community over those decades. But it's easy to do better when you've got so much data you can learn from.

I don't doubt Rust is a good language. I have yet to try it myself; that's mainly because I haven't worked on a project that uses Rust, and I haven't really looked into using it for one of my own projects.

At the same time, sometimes I'm not sure about a programming language forcing certain rules & paradigms, etc.. C and C++ let you do pretty much anything, and IMO that's not necessarily a bad thing. Just be careful not to do stuff that will cause bugs. :) I know, there's always human error, and everyone will eventually make mistakes, so I suppose it's good if the language can help avoid that. Sometimes I'm torn between that and the adage that "it's a poor craftsman who blames his tools". There's the old joke that a person goes to see a doctor and says, "My arm hurts when I move it like this," and the doctor says, "Then don't move it like that."

These conspiracy-theories about control, evangelism, attacks on software freedom, etc, are just uninformed nonsense.

Honestly this thread is the first time I've heard about any conspiracy theories about control on software freedom due to evangelism of a programming langauge..

Nightfox
--- SBBSecho 3.31-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

On 03 Dec 2025 at 11:13a, Nightfox pondered and said...

Re: Re: macOS 26
By: tenser to Nightfox on Thu Dec 04 2025 07:20 am

Rust is, frankly, a better language than either C or C++, but with go reason: it had 35 years of C and 30 years of C++ history to learn fro when it was designed. Plus it could also draw on lessons learned fro research in the wider PL community over those decades. But it's easy do better when you've got so much data you can learn from.

I don't doubt Rust is a good language. I have yet to try it myself; that's mainly because I haven't worked on a project that uses Rust, and
I haven't really looked into using it for one of my own projects.

At the same time, sometimes I'm not sure about a programming language forcing certain rules & paradigms, etc..

All programming languages force rules, paradigms, idioms, etc, on
programmers. Even assembly languages do this. C, for example, has
some very abstruse rules for the promotion of integers of various
types to other types; these can often surprise people who aren't
used to them. For example, pop quiz:

uint16_t mul(uint16_t a, uint16_t b) { return a * b; }

Is this little function portable and well-defined?

C and C++ let you do pretty
much anything, and IMO that's not necessarily a bad thing.

Well, except that they kinda sorta really don't. I mean,
on some level they're all Turing-complete; in the limit I
can write a Rust interpreter in C, but that's not a
particularly useful thing in the context of workaday
programming. But on a more practical level I cannot, for
example, directly manipulate the frame pointer in C code;
I need to jump to assembly for that (whether inline or
some other way).

But what people tend to mean when they say such things is
that, in C, they're programming at a very low level, and
can thus manipulate the state of the machine in a much more
direct way than in, say, Python or Java. But that's ALSO
not really true, because 9 times out of 10, programs that do
that kind of thing need to rely on some sort of externally
defined standard (e.g., an ABI like the SVR4 one to define
the size and alignment requirements of primitive types, and
define the details of structure layout and function calling
conventions). And when doing so, one has to be _really_
careful to avoid the dreaded, "Undefined Behavior". I've
seen C programs that have "worked" for decades suddenly
break when a compiler got a point revision, because it
turned out the program relied on the compiler behaving a
certain way for UB, and all of a sudden the compiler started
treating that differently. A lot of programs that people
think are "correct" are really only correct on accident
because older compilers had relatively sensible behavior for
things like signed integer overflow, aliasing, and so on.

I've written a couple of kernels in Rust (and of course some
assembly code) and the bits of C that make it usable to
manipulate low-level state are _also_ available in Rust.
*Plus* I get goodies like iterators, sum types, type-safe
IO, bounds-checked slices, pattern matching, parametric
polymorphism, closures, sensible scoping rules, explicit
type conversions (with error checking!), language-level
support for error checking via the Result monad and `?`
operator, traits, built-in support for unit testing, and
so on, that I just don't get in C. The canonical build
system even supports a robust library ecosystem.

Some of these I can get in C++, but not all; it's like the
Rust designers sat down and said, "gee, what would it look
like if we designed a language that fixed the major problems
in C++ that we've observed over the last 20 years?" :-D

Just be
careful not to do stuff that will cause bugs. :) I know, there's always human error, and everyone will eventually make mistakes, so I suppose
it's good if the language can help avoid that.

That's really the thing. 50 years of experience have shown that
our best and brightest programmers write buggy C and C++ code.
"Just write correct code" simply doesn't work, even for some really
brilliant people. The best engineers know that the most robust
artifacts come from using many approaches to improving quality:
better languages, better practices, better tools, etc. These are
not training wheels on a kids' bike, they're chain guards for power
tools.

Sometimes I'm torn
between that and the adage that "it's a poor craftsman who blames his tools". There's the old joke that a person goes to see a doctor and
says, "My arm hurts when I move it like this," and the doctor says,
"Then don't move it like that."

Ah, but the skilled craftsman also carefully curates, maintains,
and selects the tools for the job at hand. It is the poor craftsman
who reaches for a hammer when a screwdriver is called for.

The experienced craftsman is always looking for newer, better tools,
and understands that often the safer tool yields the better finished
product: the bespoke jig for moving the large panel across the saw
allows the craftsman to concentrate on the cut itself, because the
piece is secured and won't kick-back, as it is not being forced
through at an angle. Similarly, the plane iron is kept sharpened
and clean, and the sole waxed and square. Not only is this safer,
the resulting work is higher quality.

I don't, generally, remove the guard from my chainsaw, even though
I try to be very careful when I use it. Why should I treat the tools
that I program with differently?

These conspiracy-theories about control, evangelism, attacks on softw freedom, etc, are just uninformed nonsense.

Honestly this thread is the first time I've heard about any conspiracy theories about control on software freedom due to evangelism of a programming langauge..

The Rust-in-Linux people have faced a lot of resistance from a
number of long-time developers who are resistant to moving away
from C; most of that is FUD. But it gives fuel to a number of
ankle-biters swirling around the Linux community make these
sorts of wild claims, but they don't tend to produce a lot of
software: no one takes those people seriously.

Similarly, Rust does have a problem with too many fanbois who
blame _all_ software problems on failure to write everything in
Rust. Those folks _also_ don't tend to write a lot of software,
and again, no one takes them seriously. But their behavior
tends to interact with the Linux peanut gallery types to create
a pretty toxic mix, and amps them all up. The result is a lot
of noise and heat, and almost no code, but everyone else has to
wade through this ridiculous and unnecessary cesspool.

Torvalds seems pretty bullish about Rust in the Linux kernel,
though, so we'll see where it lands up; OTOH, the maintainers
keep burning out and quiting because of the FUD and the
crazy nonsense.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)