> I seem to recall that early versions of Linux wouldn’t run on a cheap 386sx until the kernel started to incorporate embedded applications from widespread use in the late 90s.
I ran Linux on a 486SX with 4MB RAM in early 1994. Prior to that (1993?) I had been running 386BSD. Both OSes ran quite well on that hardware: certainly sh, vi, gcc, and make ran well, and what else do you really need?
4MB wasn't good enough for X Windows, but I had a VT102 connected to a serial port so that I could have two terminal sessions going at the same time.
I agree with the article that there is a lot of low-quality "journalism" out there, designed to outrage or entertain rather than inform.
However, that does not mean that all journalism should be disregarded. I read the Washington Post and listen to NPR (regardless of how you feel about their cultural programming, their news organization is excellent.) Citizens in a free society have a duty to be informed about the issues facing that society. I reject the idea that there aren't readily available high quality sources of information about the world. Are any of them perfect? Clearly, no. But ignoring them because they're not perfect strikes me as nihilistic.
There's one quote from the article that alarmed me:
> The news is overwhelmingly about things you cannot possibly influence
I tried proper left hand mice for a while (naturally-right-handed, switched to left-hand mousing for RSI reasons similar to above), and eventually I just embraced the idea of using a right-hand mouse with my left hand. It feels completely natural now. As an added benefit, I can use any "normal" mouse by just moving it to the left of the keyboard.
I've had good experiences using Upduino 3.0 and 3.1 [0] with the IceStorm tools via apio [1]. I wrote a blog post [2] with some info on getting things set up via Linux. All you need is the Upduino board, which interfaces to your host system via USB (so no special programmer is needed).
> And if you want a portable computer (which by the way are demonstrably more secure in the face of physical tampering) you basically relegate yourself to terrible battery life, poor display support, dicey sleep support, and the fixes for these often compromise performance.
This depends a lot on how well supported your hardware is. I run Linux Mint (MATE) on a Thinkpad T430 and have had 0 issues with displays, sleep, battery life, you name it.
> Jekyll should work on Windows because Ruby works on Windows.
Jekyll is a bit of a nightmare on Windows at the moment, at least if any significant part of your workflow is based on cygwin. (I helped a colleague get it running a couple weeks ago.)
Cygwin ruby + gem install jekyll -> fail.
rbenv to build ruby from source under Cygwin, gem install jekyll -> fail.
The one solution I found that works is using Chocolatey [1] to install ruby and then gem install jekyll. Even so, I wasn't able to get pygments working for syntax highlighting, and the Chocolatey Ruby does not play nicely with cygwin terminal for interactive programs.
> jOOQ is SQL-centric. Your database comes "first".
This approach has always seemed completely backwards to me. Isn't the database simply a mechanism for persisting records/objects whose structure is determined by domain modeling?
To me, it would make about as much to say of a GUI framework "foobarWidgets is GUI-centric. Your UI comes 'first'.", as though the application itself was just an afterthought.
Don't get me wrong - I like SQL, and I happily use relational databases to store objects. I just see the database as a means, not an end.
It's a fair question whether the visual/blocks model is appropriate for expert programmers. However, there was some research presented at ICER 2015 showing that visual/blocks languages have benefits for students learning to program. Mark Guzdial had an interesting blog post[1] about it.
I have a couple T61s from Ebay that I got for my kids. I've been using one of them for some development work, and I've been surprised at how well they work for that purpose --- as in, I could easily use one for my day to day work. Put an old SSD in one, install Linux, and you have a very nice machine.
Don't write a game engine: write a game. You won't really know what features your engine will need until you have specific requirements. The generic parts - the "engine" - can be extracted via refactoring once you have a working system.
> This doesn't surprise me. The whole academic publishing side of things is a royal pile of shit. Glad someone is calling them up on it.
The ACM, at least, allows authors to post copies of articles on their web pages. That's a not totally unreasonable policy (although the ACM Digital Library is pretty well locked down).
I completely agree that IEEE is evil.
Random fact: Peter Suber was my academic advisor in college! Incredibly smart and nice guy.
First of all: I think the US education system (at both K12 and college/university levels) is deeply disfunctional.
However, I can understand and sympathize with a teacher's desire to understand how his or her students are using their time outside of class. In particular, knowing that a student who is struggling is not studying or is only attempting to cram at the last minute could be useful information for finding a strategy to help that student to improve.
I think the real problem is that many of the students I see (I teach CS at a small college) are focused on the external artifacts of education --- grades, a degree, etc. --- and not the actual learning. If students don't see an intrinsic value in what they are doing, they will try to game the system by cheating, memorizing instead of learning more deeply, etc. Over time I have come to realize that one of my duties as an educator is to try to motivate students to learn. As such, any information available to me that will help me understand whether or not a particular student is using his or her time effectively outside the class is valuable.
Sparkfun (http://www.sparkfun.com) has some good tutorials. "Beginning Embedded Electronics" is a good place to start.
I personally got started with microcontrollers and digital electronics by reading "The Microcontroller Idea Book" by Jan Axelson. It's a bit dated, but very well-written, and for me it was the first time that hardware really "clicked". I still refer to it from time to time for ideas for interfacing I/O devices.
True emulators like Bochs are still potentially a win if they provide fine-grained debugging features. Bochs was nice because you could single-step through assembly and view contents of registers/memory quite easily. You could also attach gdb to it (although this was somewhat flaky.)
Back in the day when I was playing around with osdev, I ran my code in the Bochs emulator. WAY easier than running on actual hardware, especially starting the emulator was 10x faster then booting on an actual PC.
I do remember the excitement of getting interrupts to work - good times. Getting task switching to work was magic.
I'm a huge fan of the Bolt, and I love my 2019. It's a very practical car, and has surprisingly decent range.