Years and years ago he talked at my university lug. I picked him up in my car from the train. The BO smell remained in my car for WEEKS. Dude had a serious aroma.
On the other side, back in college to earn extra money, I was his typist for around 10 hours (3 or so hours at a stint), meaning he sat diagonally behind me, reading the screen I was typing on. The only thing I noticed was his hair was a little wild.
That was a few decades ago, so perhaps things have changed, but he was well within normal odor back in the early 90s.
Everything. He would sit behind me and dictate keystrokes (mostly driving emacs, of course) to do email, edit code, and generally operate the computer. I don't want to talk about someone else's medical situation, but I think it's well-enough-known that rms had a period of RSI so severe that he was barred from using a keyboard to let his wrists/hands recover.
A few hours in a row of hearing and typing C-Space C-u 2 4 M-w C-x C-b <RET> C-y C-x C-s is exhausting. It was also amusing (in retrospect) to get a polite-enough admonishment to "don't think about what the keystrokes are doing; please just type what I say" when he could tell that I was slowing down because I was paying too much attention to what the intent behind the keystrokes was.
I learned a lot, but I wish I could have gutted it out for longer in order to learn more about emacs and gcc internals. (I knew "we" were doing some maintenance on gcc because I remember asking questions about a comment that said "this is a win" and asking rms if we were working on gnu chess and him telling me that it was a compiler optimization. [Yeah, that's how amazingly skilled I was at the time.])
I ended up doing 4 sessions totaling about 10 hours and when I told him I was quitting, I was apologetic that I felt like I'd wasted his time quitting so soon after starting. His response I can remember to this day and it was something like "Don't worry about it; most people quit after the first session. You helped me out and we'll make sure you get your check."
That's amazing, it feels similar to people playing chess in movies (not sure if it happens in real life) without the board, just remembering the positions.
FWIW, there is a rare medical condition some people have, where their body odour is abnormally high. I knew a girl in high school, very attractive and a wonderful person, but she sufferred from this condition, despite her best efforts to manage it. She would be regularly bullied by the girls and rejected by the boys for it.
stallman doesn't have some highly rare medical condition, he's just a lazy hippy programmer type. and it sounds like he's got reasonably decent hygiene.
I'm a CS grad student at Caltech. My absolute favorite intro theory book (the one I recommend to undergrads and people just starting out) is Algorithms by Vazirani, Dasgupta, and Papadimitriou. Extremely well written and a great selection of topics.
The ports that receive -stable updates in CVS. That usually means important security fixes, chosen at the discretion of both the port maintainers and developers building stable packages. The @OpenBSD_stable Twitter account may be helpful, ports tagged OPENBSD_6_5 are stable updates, and should receive updated packages.
Is this the same as what mtier provides ? Or are the packages different. I was trying to find chromium as that is about the only internet facing package I would use in a hypothetical desktop setup. I didn't see it on the link you posted.
Unrelated. I don't know what all mtier provided, but chromium port updates are not backported to -stable. A quick check indicates they did not provide this.
Also note that mtier announced they will no longer be providing -stable packages of their own.
If you want the latest chromium, you need to run -current snapshots. Packages are available. Chrome is enormous dwarfing the OpenBSD kernel and base system combined and is under constant development, it's a challenge to keep updated on -current, let alone attempting newer versions on -stable.
What he states is that if n <= k, then we run in O(1) time, which is correct, because array lookup is O(1):
return fibonacci[k]
This is the canonical benefit of memoization, further clarified by this quote: "This solution has an O(k) space and time complexity for the first query."
In reality, array lookup is not O(1). It's orders of magnitude faster to do random lookups in an array that fits in L1 cache than one that doesn't. The cache hierachy makes array lookups O(log(n)) or possibly even O(sqrt(n)).
I think you overestimate the number of programmers that know this. In my experience, < 50% of programmers know that random array lookups are not constant time in practice.
I mean they would be able to deduce it, but they just never made the connection.
Hey Walter, I really admire your work. I'm curious though, do you think D is potentially in danger of trying to do too many things? No one wants another mess like C++.
I do not think it is in danger, it already does too many things that make it a complex language. Similar with Object/Free Pascal and to some extent C# and certainly others i cannot think of right now.
These languages are like horses running on a straight line towards maximum complexity. It is just that C++ is at the front right now, but no horse has any inclination of stopping.
Not an exception really, there are many simple languages and Oberon-07 (the dialect linked) is indeed an extremely simple one. Go is another language that is simple. And of course C (that compiler developers abuse undefined behavior to win artificial benchmark games and making the life of everyone using C for practical purposes miserable is not a problem with the language itself but with the compilers that do such abuse).
This depends on if you see Oberon-07 as a different "version" of Oberon or as a different dialect belonging to the same family. Personally i see it as a different dialect instead of being the same language exactly because it removes functionality and isn't compatible with it.
It may not seem like a big difference, but it becomes more apparent when you consider how different all the Pascal dialects that are out there - some even from Niklaus Wirth himself - are.
Also IMO languages should not break backwards compatibility.
Wirth — at the age of 85, no less! — is actively working on Oberon stuff, like the compiler. Here's his "news" file, which is up to date as of May 31, 2019:
Are there shops that will take advantage of this stuff by limiting what features they use and following a certain style? For ex would a C++ team use some functional approach or a Rust style approach to ownership etc? Or it always just a mishmash?
I used to run Debian, but I switched to Fedora a few years ago and haven't looked back. Fedora is always sleek and up-to-date, unlike Debian, which due to its outdated packages always ends up looking like the plain step-sister. I also strongly prefer DNF to apt. With that being said, they both play crucial roles in the Linux ecosystem - Debian being the base for Ubuntu and Mint, and Fedora being the distribution which upstreams the most code.
Running Debian testing is generally the practice I recommend on systems which are single-user, like desktops and laptops. It's quite stable and very up to date, except for a couple of months in the run-up to freeze.
As a long time Debian user, I think you're doing Debian a disservice giving that advice. Debian testing is stable... except when it's not. Tell people that it's relatively stable, not that it's stable. And please don't tell them to run their daily driver on it unless they know what they're potentially getting into.
My own experience is that things can be broken for months in testing and of course good luck finding any help when that happens. For example, since the freeze for Buster I had broken sound drivers for a couple of months until someone else found that it wasn't actually the drivers but another broken package that as of a month or so ago still wasn't fixed (but the problem had been reported)
That's been my experience with testing for the last 3-4 Debian releases: it works great... except for a handful of annoying bugs that seem to linger almost until release. And assuming you know exactly which package is broken (which can be difficult to narrow down for driver/system level issues), you may or may not get the problem addressed in a timely manner. Then there's also the case of the occasional package that you depend on that disappears from testing for a month or two for any number of reasons.
> I had broken sound drivers for a couple of months until someone else found that it wasn't actually the drivers but another broken package that as of a month or so ago still wasn't fixed (but the problem had been reported)
I had the _exact_ same problem (the issue ended up be a MIDI program called timidity). The main problem for me was that Debian doesn't give any advice on how to report such issues (the website is firmly planted in the early 90s), and the mailing lists I found all appear to be dead. I wish Debian had a slightly more modern website.
That would be the one! I posted a stackoverflow question along with my workaround not knowing the cause. Fortunately, someone else identified timidity as the root cause. Definitely one of the stranger issues I've run into using testing in recent years, but far from the only one.
Yes, big transitions with desktop environments can lead to glitches for a while too. Theoretically independent parts can be upgraded at different times, but show subtle compatibility bugs not captured in the dependencies. I experienced this with big KDE Plasma updates. Nothing too big, and when you know about it it's easy to avoid with temporary pinning.
Like all rolling distros, it's best to be a bit technically savvy and know your way around the distro to handle those glitches. That's the big interest of stable: no bad surprise. Stability is not just lack of bugs, it's also lack of changes with the unavoidable little regressions here and there. There's room for both stable and current, but it's different and criticizing stable because it's stale misses the point IMHO.
Anyway, I agree with you that testing (and rolling distributions in general) are probably not a good idea for newcomers. For those who like to roll their sleeves and dig in once in a while, and like to learn, then fine.
Also, people usually don't need the latest in all. So stable with a few select up to date packages is usually a very good compromise. Just get the latest for what you really care about, and for the rest the no worry but slightly old is just fine. With flatpack/snapd and each language package manager this mix and match is really easy to do and probably a better trade-off than a rolling distro for many people (but not all, so just use what's best for you).
I think it's reasonable advice if the user explicitly wants a rolling release, and knows what that entails.
What other options do I have if my criteria are:
- rolling release
- not Arch
As far as I can tell, Debian testing is still the least headachy way to get a rolling release, with the added bonus of out-of-the-box compatibility with most of the "we support Linux!" software that only ever gets tested on Ubuntu.
During my ten years (five release cycles) of using Debian testing, there hasn't been an update that required get-out-the-recovery-disk levels of surgery to fix. All of them have been minor user-facing software bugs or package version inconsistencies that could be safely ignored until I had the time or the inclination to investigate. But yes, you do have to be willing to poke around a bit, and not everybody likes that.
But this is why I wanted a rolling release in the first place. I prefer to do minor repair work on a regular basis (but on my own schedule) in order to avoid major repair work every 6-24 months (on somebody else's schedule).
I also don't really mind the investigative work when something goes wrong, since it forces me to learn more about how my system works, and that knowledge invariably ends up being useful later. Some people absolutely hate this, and they would probably be better off using something else.
I've been told before that this advice isn't appropriate for anyone who isn't a Debian developer. Things can break and testing may not get important security patches until a while after unstable and stable.
Not a Debian developer here. I've been running both Debian testing and unstable on various machines for about a decade and it's been great.
In my experience, the "here be dragons" description of testing/unstable is way overstated... they're both very reliable. If you install apt-listbugs and `apt-mark hold` anything with bugs that sound scary, you'll be fine.
It seems like a lot of people try Debian stable (perhaps thinking of it as an upgrade path from Ubuntu), are surprised by the ancient software packages, and then look elsewhere. Debian might want to consider changing the recommendations they make for new users. Instead of stable / testing / unstable, they could be server / workstation / testing.
I think that having to check the issue tracker before installing packages is exactly the kind of thing that people are talking about when they say "here be dragons". By your argument, we would also be able to call Arch Linux a very reliable distro. It can be if you know what you are doing, but it isn't something I would want to recommend to the average user...
> Instead of stable / testing / unstable, they could be server / workstation / testing.
I would love to see something like that, but I think it would need significant changes to Testing to make it usable for the masses. Some years ago there was some work towards that direction with Constantly Usable Testing, which explains some of the challenges: https://old.lwn.net/Articles/406301/
The security patches is certainly a concern (though testing-security does exist, albeit not with the coverage of security-updates from stable). In my experience, testing is quite stable for 95% of packages; I can only think of a few instances in the last decade that testing has really broken my computer in a way that required me to break out my developer skills. More frequently, you'll find packages which can't be installed because they've been dropped from testing due to RC bugs -- but that's not necessarily a bad thing!
I've had a more pleasant experience using Fedora than Debian Testing.
Debian is great in general but the wonkyness surrounding the freeze period gave me the impression that Debian Testing really is something that should only be used if you are interested in helping Debian produce the next Debian Stable release. Some packages don't get timely updates and are only updated close to the freeze period, in preparation for the next stable release. And during the freeze period itself everything is super awkward because preparing the next stable release takes priority over keeping Debian Testing usable.
I've used Debian unstable and agree, but given that most packages in testing usually only lag behind those in unstable by a few weeks... any particular reason?
That's kind of the same question I would have about choosing testing over sid.
If the intention is to be on rolling-release, you might as well just use sid. If you'd rather just be on rolling-release until the stable release is carved out (new features desired, for example), testing is pretty fine since it will transition into being the stable release.
In my experience, testing is (across the entire release cycle) often more buggy than sid, especially as it will get scant detailed attention in, say, the first year after a stable release. Using testing (for me) is usually just another annoying speedbump too - for example, one's issue is usually fixed in unstable and you are "just" waiting for it to migrate but it won't due to some boring, unrelated reason about 7-dependencies deep that might take a week or so to be resolved...
Running Debian, and in my case Devuan never leaves me hanging. Ubuntu and similar distro's often break everything with a regular update. Thanks for your hard work, a huge fan for 20 years+!!!
Debian Testing is always more or less up to date and in the several years I've been using it I've never encountered a system breaking bug. It all seems to get ironed out in the Unstable branch.
On the contrary I left Redhat at 8.0(long time ago, before Fedora) and started using debian/ubuntu and never looked back, in my opinion, while Redhat made a fortune by its business model, Debian and ubuntu are the true community OS, I can't ask for more.
Ubuntu/Debian has been my primary Desktop/Server for the last 15 years, life is good with them. Thanks so much for the maintainers and contributors to put so much efforts into them.
Debian is as sleek as you want to it to be, in your case if you're after bleeding-edge packages the release you want to try is either Testing or Unstable, not Stable(in this case aka. Buster). APT was recently updated and shortened to a 3 letter command(à la DNF) and is now run as simply #apt update.
I used Debian on servers and something more recent for my desktop (Fedora or Arch), but recently I've been playing with openSUSE since it has both use cases covered, as well as an enterprise upgrade path.
I love Debian and I'll always recommend it for servers, and it makes a reasonable desktop too. However, it's not right for everyone.
Been meaning to ask a Fedora user... does it still rely on 3rd party repos? I switched to Debian around RHL 6 or so due to the reliance on 3rd party repos and I know RHEL/Centos still rely on it and was curious if Fedora did?
Take CentOS for example... No 3rd party repos are required to run the system, but everywhere I've seen CentOS used in production they've installed packages from EPEL.
Used to code quite a bit in Haskell, but I've moved on. I believe in the philosophy "Simple things should be easy, hard things should be possible"; Haskell forgets the first part.
