> Yeah it's cool to be able to watch all this crap from my childhood, and a thousand great tv shows or movies, or hundreds of the best video games yet made, or browse endlessly for new music tailored to my tastes, or whatever, totally on demand—but maybe that kind of thing's just not healthy to have around.
I feel the same, although I have a hard time articulating it well. I think I'm slightly better at not watching hour after hour of utter garbage than I used to be, though.
You seem to be defending against a claim the study does not make. They're not saying "smartphones make us stupid because Google's in your pocket!" Rather, the study is saying that by having your phone on the desk or even in your pocket, you will exhibit decreased mental capacity because your brain is using some cognitive resources to monitor for notifications etc.
This may be over-simplified but appears to be backed up by the general discussion on pages 10-11.
> And before you go all Luddite on me ... "That sounds terrible!" I actually rarely take my phone with me and 90% of places I go have no signal. So for me this technology is almost like magic (if they can make it work)
The way applications are written today, your HoloLens won't be able to show you information about planes and ships and such without an Internet connection :(
And that's sort of the point, in my mind: the page is about a megabyte, while something comparable on the modern sites he's talking about would be many times larger. As you say, it's a megabyte because there's a megabyte of content, not a megabyte of Javascript and trackers and "From Around The Web"
Back when I was on 28.8K dialup, I'd typically figure I could fetch a megabyte a minute. Because the site is just plain old HTML, even over a terrible connection you'll be able to start reading pretty much immediately, and the images will pop in as you go. It's a good user experience.
A group of Slashdot users moved to comp.misc when Slashdot made some significant changes they disliked, and there's still some relatively lively discussion over there.
On paper, Overdrive is everything I want, but every time I try to use the damn Android app it makes me want to just drive to the library instead. How many times should I need to enter my library card # to check out an ebook?
Wrote my own thing on top of Go's http package. It handles subdomains to a limited extent and will also serve Markdown-formatted blog entries. I run it on a RAM Host KVM-based VPS, which I also use as a shell box and a traffic-forwarding endpoint when I'm on untrusted networks. The RAM Host VPS is a little expensive but after some incredibly frustrating experiences with the idiots at ChicagoVPS, the lack of drama has been well worth it.
Does Sonic.net not provide service in Berkeley? Back when I lived in the Bay Area, I switched from Comcast purely because Sonic.net isn't an utterly loathsome company. Turns out with Sonic I didn't have to reboot my modem every other week either.
Plus, unless you're buying a $5000 medium-format DSLR, your 35mm film camera has a larger "sensor" size than the digital camera. And if you spend $100 and buy a medium-format TLR, well, now your negatives are 6x6cm and holy crap that's a lot of detail.
I don't have numbers but in general I'd call it no less usable than X forwarding over ssh. For a long time I used to connect to a Japanese Plan 9 server using drawterm (a Windows/Linux application which essentially emulates the /dev/draw infrastructure) and it was pretty decent considering the latency--I used it to read email, follow IRC, and write code. Over a LAN, it's so fast as to be indistinguishable from something running on your local machine.
You're right, but first the INSTALL script makes a few customizations based on what OS you're running (Solaris, OS X, Linux, *BSD), then bootstraps mk and finally runs mk on all the application source.
The script takes into account differences in operating systems, without including thousands of lines of weird little leftovers from 30 years ago when you needed to check if you were actually running on a 16-bit Data General machine or whatever (I'm looking at you, autoconf)
Lisp machines were expensive, the early ones at least took a very long time to boot, and I think there are weaknesses to the Lisp "image"/"world"/whatever model that Lisp-M partisans aren't quite willing to acknowledge. They're still extraordinarily cool machines.
Plan 9 did it in an interesting way. You draw to the screen by writing to files under /dev. On Plan 9, all file operations take place over 9P, a networked file protocol. So if you are connecting to a remote machine and want to run a graphical program, you mount your local /dev/draw files on the remote end (this is actually taken care of automatically by cpu(1)) and just run the program. Its graphical functions access your local machine's /dev/draw and it all Just Works. Hard to explain but very neat when you use it.
You should be able to build well-written code on a variety of modern systems using nothing more than a Makefile, or even just a shell script. See plan9port for an example of the latter.
If you look at Plan 9, you'll see /usr is once again the location of user home directories, and binaries go in /bin. In fact, /bin is a 'union' directory composed of /386/bin, /rc/bin, /usr/jff/bin, and any other places you've decided to put binaries.
Regarding 'ls', I ran "strace ls" on Linux and didn't see any open on /etc/password; it's important that you run 'ls -l', which should trigger the /etc/password access because it has to map UIDs to usernames.