91–100 of 111 posts
Earlier quoted context omitted.
JWZ may know his stuff, but damn he can be a salty asshole...
What an interesting fellow! I'd like to subscribe to his newsletter.
Earlier quoted context omitted.
JWZ may know his stuff, but damn he can be a salty asshole...
I usually like to leave more substantive comments on HN, but I don't think he would be mad if I said "that's kind of his thing."
Heh, and while writing this it dawns on me that it may well be that he is about OSX because UNIX. Meaning that OSX is a BSD derivative, that in turn is derived from the historical UNIX. While on the other hand Linux is just a bastard clone.
Because it hit me that i have seen some similar fervent anti-Linux sentiment from other UNIX people, related to either the BSDs or Solaris.
Earlier quoted context omitted.
Operating systems and drivers will allow rotation of most monitors and it mainly comes down to a matter of mounting hardware if autorotation isn't a big deal. Monoprice has a stand for about $20. http://www.monoprice.com/product?c_id=108&cp_id=10828&cs_id=...
There is an non-obvious caveat to using vertical monitors on Windows though - ClearType font rendering doesn't support vertical subpixel arrangements, so you're stuck with naive anti-aliasing.
Certainly screen rotation (with windows tablets and phones) would involve a lot of inefficient re-rendering. But i think the official reason was that since the subpixel colouring effect depends on the background colour, it's hard to animate transitions efficiently.
On a high-DPI screen, you'd be hard-pressed to notice the difference compared to greyscale hinting. Colour subpixels were a great hack, but high-DPI is the proper solution to this issue.
Earlier quoted context omitted.
Thanks for the info, gumby. As you point out, the amount of bus bandwidth consumed by the display is a big thing. It seems a bit crazy that the processor was running microcode to copy all the pixels to the display in 16-word chunks, 30 times a second. (In a "normal" system, the video hardware fetches characters or pixels from memory. But in the Alto, the processor was running instructions to feed the pixels to the di…
> It seems a bit crazy that the processor was running microcode to copy all the pixels to the display It seems crazy today but not in context. There wasn't video hardware in today's sense. There were either mainframes (with channel controllers) with the terminal doing the "rendering" or minicomputers and microcomputers in which the CPU did everything (which is what I guess it was like before the mainframe era). You c…
http://www.c64-wiki.com/index.php/memory_map
If you wanted to do IO on the C64 for example you manipulated RAM addresses between D000 and DFFF.
My uncle worked at PARC when this was being made. I probably wouldn't of gone into tech, if it weren't for him. This makes me want to message him and ask him about his time there.
> The disk drive at the top of the cabinet takes a removable 2.5 megabyte disk cartridge. The small capacity of the disk was a problem for users, but files could also be accessed over the Ethernet from file servers. (...) > The Alto was introduced in 1973. 2.5 mega bytes of removable/swappable storage ? In the 70s? I'm amazed that users found it constraining! That's more than even the Amiga managed to fit on 3.5" flo…
Keep in mind that although the Alto disk is removable, it is a hard disk, not a floppy; the user normally kept it mounted for a session, rather than using a new disk every time they load something. Thus, the disk needs to hold everything you need. (Although you could access files over the network with FTP.) The user guide describes in great detail [1] why Alto users found 2.5MB of disk limiting. To summarize, the dis…
Interesting to note (as @pjmlp mentions) that 1973 + 15 years leaves us at around the time the Amiga 2000 was introduced. I remember ours (a model b IIRC) initially had a 20MB hard-drive, later upgraded with another 40MB for a total of 60MB of storage. It could fit almost all of my floppies on there!
Looking at the wikipedia page for the Amiga 500 I see the RAM latency listed as 150 ns. I'm not sure if that's the actual latency to read data from RAM - if so it's within an order of magnitude for accessing RAM today! (I'm also a little sad that while my i7 is a lot faster than that ageing 68000 that ran at 7.5 Mhz, it's still not easy to find a single core with 7.5+ Ghz of performance :-( ...).
> The disk drive at the top of the cabinet takes a removable 2.5 megabyte disk cartridge. The small capacity of the disk was a problem for users, but files could also be accessed over the Ethernet from file servers. (...) > The Alto was introduced in 1973. 2.5 mega bytes of removable/swappable storage ? In the 70s? I'm amazed that users found it constraining! That's more than even the Amiga managed to fit on 3.5" flo…
As Alan Kay states on his talks, for doing this type of research one needs to imagine how the hardware will look 15years from now and build such hardware, regardless how much expensive it might be.
The Alto was not meant to be a personal computer but a "personal supercomputer"—hardware so far ahead of the curve that it could run the software of the future. In other words, not a personal computer but a machine for inventing personal computing with, which of course they proceeded to do. Having such hardware is what makes it possible to figure out what the software of the future needs to be. If you can't run it, you can't create it.
For me this sheds light on a couple of Alan's famous lines: that the best way to predict the future is to invent it, and that people who are serious about software need also to be serious about hardware.
Such advanced hardware is necessarily costly but should still be within the reach of a properly funded research lab. It seems to have been an enormous frustration to Alan and his colleagues that they were unable to persude hardware vendors to make such hardware at any price, especially the Alto's microcode-driven style of hardware. Among other things, that was what had enabled the PARC researchers to make the most of the limited memory they had, since when a task was consuming too much memory they could implement it in microcode, pushing it down to the hardware (at least from the software's point of view) and freeing up RAM for software.
Earlier quoted context omitted.
As Alan Kay states on his talks, for doing this type of research one needs to imagine how the hardware will look 15years from now and build such hardware, regardless how much expensive it might be.
This point is so important that Alan has emphasized it as one thing we're mostly missing. The Alto was not meant to be a personal computer but a "personal supercomputer"—hardware so far ahead of the curve that it could run the software of the future. In other words, not a personal computer but a machine for inventing personal computing with , which of course they proceeded to do. Having such hardware is what makes it…
It's important to remember that the Alto was called the "interim Dynabook", a system to try out the Dynabook ideas until technology caught up and made a Dynabook-like system possible (40 years later).
[1] http://history-computer.com/Library/Kay72.pdf - jump ahead to page 6 for the hardware details
Did the Alto have a graphical chat system?
We've all been fans of Ken's blog for years, so were thrilled that he took an interest in this project. Not only is Ken doing these amazing writeups, he gathered together the master restorers and engineers, some of whom worked on Altos at the time, who are now working on this one. Seeing them set to it, inspecting the Alto and figuring out what would be needed, was a lesson in self-organization. It was an honor to wa…
I have a Symbolics XL-1200 that I've been wondering what to do with. Would YC like it? It worked the last time I turned it on, but that was 4 or 5 years ago, probably. It's like triple-pizza-box size, not a refrigerator nor even the size of the Alto.