a) That work-around doesn't work for me, for whatever reason, and b) it doesn't change the fact that Gecko text rendering is broken, because it's completely legitimate to have fonts (even duplicates) in a personal Library/Fonts directory. No other applications make a hash of it. Safari manages to get it right.
Ever since Mac OS X 10.4 or there abouts, Gecko (Firefox has the same problem) has been unable to measure text properly, for some reason. Many pages end up with text hanging raggedly out of the right hand side, white space is missing in front of links, or else links completely overlap the surrounding text. Text entry boxes are unusable because the cursor winds up somewhere to the left of the most recent character entered. I used to love Camino, and I try all of the betas, and post updates on bugzilla, but it's just useless to me at the moment. Pity. Safari isn't that bad, after all.
I haven't read the whitepaper yet, but the front page article makes it sound a lot like any of the OSes listed above. What's new here? Not to mention any of the proposed (but not deployed?) Java OS systems...
Using an emulator (bochs, VirtualPC, etc) is a fine plan, but you wouldn't want to have to use it for editing and compilation: too slow and clunky. Get the gnu toolchain up in a cross-development way, either through debian GNU-darwin or (my preference) the NetBSD pkgsrc tree.
Not to mention any of the dozen X11-based, NeWS and NeXT versions of this idea that have existed over the years. No one uses fvwm's GoodStuff any more? Or WindowMaker/NeXT DockApps?
Wake up and smell the coffee guys !! We are now well into the 21st Century and Linux is still using a printing system that appears to have been written in the 1960's. This needs fixing with a solution that is small, fast and easy to use.
Naah. Here in the 21st Century we don't waste trees to convey or store information. That's what e-mail and PDF files are for.
[To the topic, though: CUPS/IPP is great. USB printers are great. My Lexmark 312foo is hooked to CUPS on my NetBSD box, and all of my other computers (WindowsXP, MacOS-X, FreeBSD) all just use it. It's fast, and easy. OK, so it took some fiddling to set up correctly, but you only have to do that once.]
It's been going for several years now: I bought my "Happy Hacker" keyboard from them, and that's nearly worn out now. They're still going, too. Bricks, mortar and all (and a web presence, of couse).
Just run your own IMAP server. Courier IMAP uses the Maildir store in your home directory, just as DJB intended. So all the messages are files in directories, and you can muck about with them however you like, back them up, find them with a search engine, whatever.
I've heard that the IMAP protocol is nasty and has never been implemented twice compatably, but the functionality is just about perfect for mail.
I use qmail and courier to concentrate about four or five different mail feeds and a few lists, and I can access my mail with mutt or evolution or thunderbird, or [insert most mailers here] from anywhere on the network.
The easiest way to export your mail (and import it into another mail client), by far, is via an IMAP server. Just set up an IMAP server, and an account on it, copy your mail tree across to that account...
...and then never bother to copy it back to the new client. Just use your mail on the server.
NetBSD has X in the base distribution, and they've upgraded to XFree86-4.4. Not sure how many of their 40+ supported architectures support X, but it's bound to be more than just x86.
Small-screen laptops: yeah, I own one too. I still don't run my applications maximised, most of the time, and even when I do, the other windows are still there under Alt-Tab. This is a stupid argument against drag-save, though: if you can make a dialog window open above your current window, and you can click on a link in your e-mail window to open a new web browser window, you can jolly well automatically open or raise the appropriate file manager window too.
Lines too long: yes, of course I mean horizontal text. Does anyone actually read something like slashdot in a maximized browser on a 1280 or larger screen? I like my text columns to be shorter than 20cm, myself.
Naming internet downloads: so they've already got a name. Yay! No need to type anything!
Drag-to-open, or drag-to-save vs inability to mouse: tab to select icon (probaby selected already though), ctrl-x, alt-tab to select browser, ctrl-v. Same as you do when copying files in Windows. It *is* a copy operation, after all. There are probably better methods and shortcut combinations that can be built for common situations, of course. For myself, I prefer to mouse most of my uncommon menu operations, even though I touch-type. I use a trackball that sits next to my happy-hacker keyboard, and I find that faster and less effort, most of the time.
Thankfully, the most important part of the GTK+ upgrade is the API upgrade, so it will probably be possible to build a DnD save mechanism for those of us who want it anyway.
The point isn't even really about drag-n-drop, anyway. It's about re-inventing a crippled (in whatever sense takes your fancy) directory browser for this one task, rather than just using the full-featured one that your desktop already has.
Manual? What do you call having to drill down through your directory hierarchy every time you need to access something? Directory browsers stay open after use, and know where they are. And you can have more than one open at a time. Alt-Tab is not significantly slower than Ctrl-S. Start your file manager? It's already started. We are talking about a desktop environment. Unmaximize your window? You must work with a tiny screen. I haven't used a maximized window since the days of 800x600 laptops: the lines become too long to read, usually. Still have to name it? You have to type the name in anyway. How is that an issue?
Seriously: compared to the drag-to-save dialogs in RISC-OS, and directory-browser-based opening, the whole File->Open and File->SaveAs menu process is wildly inefficient and just plain clunky.
Acorn got this aspect of GUI design right. You don't need a file selector. Opening or reading things is best done by clicking or dragging from an existing directory browser. Saving or outputting is easily done by dragging an icon that represents your file into an existing directory browser. Need to open a directory browser to do that? How is that different from needing to open a file selection dialog?
File selectors? How modal. How quaint. Just say no.
I had a Trackpoint II keyboard for a while, and it was, as you say, great.
Unfortunately, I broke it. Specifically, I broke the plastic clips on the spacebar that hold onto the metal torsion wire that keeps the whole thing horizontal. I couldn't get a replacement, so I've switched to a combination of Happy Hacker keyboard (great feel, keys in right place, small) and a Logitech Marble Mouse trackball.
I'm quite happy with the result. Trackballs are great, and don't cause the shoulder-ache that long-term mousing does. (Trackpoints don't either, but there isn't one on my Happy Hacker, and I haven't found a stand-alone trackpoint mouse gizmo.)
That's how I learned, when I was about 13. I could see that keyboards were going to be a big part of my future, so I just made myself learn. The first thing that you learn, this way, is where the backspace key is... The trouble with learning to touch-type, any way, is that your typing *will* be slower than you were as a skilled two-fingered typist for a couple of months. After that, the raw speed, and the ability to look at the screen, or books, or anything else at the same time, will make you wonder why you waited so long...
I'm not sure why a regular cp command would be using a 4kiB block size. I doubt that it does on FreeBSD.
For kicks, I just did some large file (around 450M) copies, some to/dev/null (to measure read throughput) and some to new files (to measure read+write+file allocation). I get a smidge over 24MB/s for reads, and a smidge under 20MB/s for copies. This is with the system "cp", through the file system (FFS+softupdates) on a P3-500 box. The filesystem is striped using vinum under FreeBSD 4-stable over a pair of Seagate 7200RPM 80G IDE drives (cheap). The drives are ATA-100, but the motherboard only knows the UDMA33 style. The drives are each on the separate controllers of a i440BX chipset. I.e., very standard motherboard, new drives, no special tuning done to the filesystem.
Trying again with dd instead of cp, and bs=4k, the read rate drops to 18MB/s and the copy rate drops to about 18MB/s too, so don't do that...
The wonderful thing about the internet is that it shows us that if you think about something (without doing it yourself) for long enough, someone else will do it for you:-)
The differences between XWT and my thought experiments seem to be:
(1) The renderer is monolithic: I imagined a widget-by widget system in Java: sort of an outgrowth of how NeWS was supposed to work. Can XWT be extended in this way?
(2) The comms protocol is XML:euch. I'd imagined something compact and binary, perhaps Java's RMI. Oh, well, comms bandwidth is cheap as are parser cycles, they say.
(3) I'd imagined being able to wrap the host side inside something that pretended to be one of the popular widget sets, like GDK. Then my favourite X applications would have a chance to go where X hasn't. I haven't dug into the XWT doco enough to know _how_ the host side looks. Does it match one of the existing windowing models?
Sun and Apollo arguably created the desktop Unix niche by putting BSD Unix on a micro. BSD has always been a "users" unix: that's why it had csh and vi and extended tools: people actually wanted to use it interactively.
Sure, the definition of what it takes to be a "desktop OS" has changed now, and maybe other systems do it better.
I've only ever used BSD desktops myself (SunOS, NetBSD, FreeBSD).
Re:KDE: one of the most successful OSS projects
on
KDE 2.1 Is Out
·
· Score: 1
Pan?! Pan doesn't even hold a candle to slrn! It doesn't do URL sensitisation, doesn't follow the usual news reader "spacebar does the next obvious thing" rule, and is generally a lot of work to actually use. Has promise, maybe, but it's not useful yet...
On an early-ish OS-X beta that a guy at work had, we installed sharity-light (an early version of smbfs) straight from the FreeBSD ports tree with one modification: I had to add a -DFreeBSD (or something like that) to the CFLAGS, to make the build take the right path through the #ifdef maze. Obviously the open-packages arrangement will make the source patches do the right thing all by themselves.
But: with that one change, the whole thing built and installed and ran without a hitch. That, to me, is a pretty impressive level of compatability.
Sure, it's a bit limited as an OS by todays standards, but architecturally it's neat enough, and small enough and readable enough to be printed in its entirety in the appendix of a book which describes the theory behind it. So you could think of the first half of the Minix book as one enormous meta-comment for the rest of the code, perhaps.
It's nice, clean, traditional C style, too.
From that perspective, the Unix of the Lyons book is pretty readable too.
For something non-C, the source of the SmallEiffel compiler and it's libraries (all in Eiffel of course) is a pretty nice read too. CVSup (in Modula-3) is nice. Read lots of things, in lots of different languages. Some languages seem to lend themselves to clarity of expression a little more than C or C++ do. I don't think I've ever seen C++ code that was beautiful to read.
Slashdot Mirror
a) That work-around doesn't work for me, for whatever reason, and
b) it doesn't change the fact that Gecko text rendering is broken, because it's completely legitimate to have fonts (even duplicates) in a personal Library/Fonts directory. No other applications make a hash of it. Safari manages to get it right.
Ever since Mac OS X 10.4 or there abouts, Gecko (Firefox has the same problem) has been unable to measure text properly, for some reason. Many pages end up with text hanging raggedly out of the right hand side, white space is missing in front of links, or else links completely overlap the surrounding text. Text entry boxes are unusable because the cursor winds up somewhere to the left of the most recent character entered.
I used to love Camino, and I try all of the betas, and post updates on bugzilla, but it's just useless to me at the moment. Pity.
Safari isn't that bad, after all.
I haven't read the whitepaper yet, but the front page article makes it sound a lot like any of the OSes listed above. What's new here? Not to mention any of the proposed (but not deployed?) Java OS systems...
I'm pretty sure that I remember setting up NAS to stream audio to X terminals in the early '90s.
Using an emulator (bochs, VirtualPC, etc) is a fine plan, but you wouldn't want to have to use it for editing and compilation: too slow and clunky. Get the gnu toolchain up in a cross-development way, either through debian GNU-darwin or (my preference) the NetBSD pkgsrc tree.
Not to mention any of the dozen X11-based, NeWS and NeXT versions of this idea that have existed over the years. No one uses fvwm's GoodStuff any more? Or WindowMaker/NeXT DockApps?
Naah. Here in the 21st Century we don't waste trees to convey or store information. That's what e-mail and PDF files are for.
[To the topic, though: CUPS/IPP is great. USB printers are great. My Lexmark 312foo is hooked to CUPS on my NetBSD box, and all of my other computers (WindowsXP, MacOS-X, FreeBSD) all just use it. It's fast, and easy. OK, so it took some fiddling to set up correctly, but you only have to do that once.]
It's been going for several years now: I bought my "Happy Hacker" keyboard from them, and that's nearly worn out now. They're still going, too. Bricks, mortar and all (and a web presence, of couse).
I've heard that the IMAP protocol is nasty and has never been implemented twice compatably, but the functionality is just about perfect for mail.
I use qmail and courier to concentrate about four or five different mail feeds and a few lists, and I can access my mail with mutt or evolution or thunderbird, or [insert most mailers here] from anywhere on the network.
Just say no to local mail stores.
NetBSD has X in the base distribution, and they've upgraded to XFree86-4.4. Not sure how many of their 40+ supported architectures support X, but it's bound to be more than just x86.
Small-screen laptops: yeah, I own one too. I still don't run my applications maximised, most of the time, and even when I do, the other windows are still there under Alt-Tab. This is a stupid argument against drag-save, though: if you can make a dialog window open above your current window, and you can click on a link in your e-mail window to open a new web browser window, you can jolly well automatically open or raise the appropriate file manager window too.
Lines too long: yes, of course I mean horizontal text. Does anyone actually read something like slashdot in a maximized browser on a 1280 or larger screen? I like my text columns to be shorter than 20cm, myself.
Naming internet downloads: so they've already got a name. Yay! No need to type anything!
Drag-to-open, or drag-to-save vs inability to mouse: tab to select icon (probaby selected already though), ctrl-x, alt-tab to select browser, ctrl-v. Same as you do when copying files in Windows. It *is* a copy operation, after all. There are probably better methods and shortcut combinations that can be built for common situations, of course. For myself, I prefer to mouse most of my uncommon menu operations, even though I touch-type. I use a trackball that sits next to my happy-hacker keyboard, and I find that faster and less effort, most of the time.
Thankfully, the most important part of the GTK+ upgrade is the API upgrade, so it will probably be possible to build a DnD save mechanism for those of us who want it anyway.
The point isn't even really about drag-n-drop, anyway. It's about re-inventing a crippled (in whatever sense takes your fancy) directory browser for this one task, rather than just using the full-featured one that your desktop already has.
Manual? What do you call having to drill down through your directory hierarchy every time you need to access something? Directory browsers stay open after use, and know where they are. And you can have more than one open at a time. Alt-Tab is not significantly slower than Ctrl-S.
Start your file manager? It's already started. We are talking about a desktop environment.
Unmaximize your window? You must work with a tiny screen. I haven't used a maximized window since the days of 800x600 laptops: the lines become too long to read, usually.
Still have to name it? You have to type the name in anyway. How is that an issue?
Seriously: compared to the drag-to-save dialogs in RISC-OS, and directory-browser-based opening, the whole File->Open and File->SaveAs menu process is wildly inefficient and just plain clunky.
Acorn got this aspect of GUI design right. You don't need a file selector. Opening or reading things is best done by clicking or dragging from an existing directory browser. Saving or outputting is easily done by dragging an icon that represents your file into an existing directory browser. Need to open a directory browser to do that? How is that different from needing to open a file selection dialog?
File selectors? How modal. How quaint. Just say no.
I had a Trackpoint II keyboard for a while, and it was, as you say, great.
Unfortunately, I broke it. Specifically, I broke the plastic clips on the spacebar that hold onto the metal torsion wire that keeps the whole thing horizontal. I couldn't get a replacement, so I've switched to a combination of Happy Hacker keyboard (great feel, keys in right place, small) and a Logitech Marble Mouse trackball.
I'm quite happy with the result. Trackballs are great, and don't cause the shoulder-ache that long-term mousing does. (Trackpoints don't either, but there isn't one on my Happy Hacker, and I haven't found a stand-alone trackpoint mouse gizmo.)
That's how I learned, when I was about 13. I could see that keyboards were going to be a big part of my future, so I just made myself learn. The first thing that you learn, this way, is where the backspace key is...
The trouble with learning to touch-type, any way, is that your typing *will* be slower than you were as a skilled two-fingered typist for a couple of months. After that, the raw speed, and the ability to look at the screen, or books, or anything else at the same time, will make you wonder why you waited so long...
I'm pretty sure that Sun's i386 Unix was SVR4 - based, just like SunOS5. At around that time there were a lot of SVR4 ports to i386 hardware.
Of course, there's a lot of BSD in SVR4, which is one of the reasons that the USL/BSD suit ended up the way it did.
I'm not sure why a regular cp command would be using a 4kiB block size. I doubt that it does on FreeBSD.
/dev/null (to measure read throughput) and some to new files (to measure read+write+file allocation). I get a smidge over 24MB/s for reads, and a smidge under 20MB/s for copies. This is with the system "cp", through the file system (FFS+softupdates) on a P3-500 box. The filesystem is striped using vinum under FreeBSD 4-stable over a pair of Seagate 7200RPM 80G IDE drives (cheap). The drives are ATA-100, but the motherboard only knows the UDMA33 style. The drives are each on the separate controllers of a i440BX chipset. I.e., very standard motherboard, new drives, no special tuning done to the filesystem.
For kicks, I just did some large file (around 450M) copies, some to
Trying again with dd instead of cp, and bs=4k, the read rate drops to 18MB/s and the copy rate drops to about 18MB/s too, so don't do that...
Just a ditto to all of the above. GVim on W2k-Pro is stable as a rock, and has all of the vi goodness and then some.
The wonderful thing about the internet is that it shows us that if you think about something (without doing it yourself) for long enough, someone else will do it for you :-)
The differences between XWT and my thought experiments seem to be:
(1) The renderer is monolithic: I imagined a widget-by widget system in Java: sort of an outgrowth of how NeWS was supposed to work. Can XWT be extended in this way?
(2) The comms protocol is XML:euch. I'd imagined something compact and binary, perhaps Java's RMI. Oh, well, comms bandwidth is cheap as are parser cycles, they say.
(3) I'd imagined being able to wrap the host side inside something that pretended to be one of the popular widget sets, like GDK. Then my favourite X applications would have a chance to go where X hasn't. I haven't dug into the XWT doco enough to know _how_ the host side looks. Does it match one of the existing windowing models?
If you're after prior technology, then comp.sources.* probably predates even the internet.
Sun and Apollo arguably created the desktop Unix niche by putting BSD Unix on a micro. BSD has always been a "users" unix: that's why it had csh and vi and extended tools: people actually wanted to use it interactively.
Sure, the definition of what it takes to be a "desktop OS" has changed now, and maybe other systems do it better.
I've only ever used BSD desktops myself (SunOS, NetBSD, FreeBSD).
Pan?! Pan doesn't even hold a candle to slrn! It doesn't do URL sensitisation, doesn't follow the usual news reader "spacebar does the next obvious thing" rule, and is generally a lot of work to actually use. Has promise, maybe, but it's not useful yet...
Very compatible.
On an early-ish OS-X beta that a guy at work had, we installed sharity-light (an early version of smbfs) straight from the FreeBSD ports tree with one modification: I had to add a -DFreeBSD (or something like that) to the CFLAGS, to make the build take the right path through the #ifdef maze. Obviously the open-packages arrangement will make the source patches do the right thing all by themselves.
But: with that one change, the whole thing built and installed and ran without a hitch. That, to me, is a pretty impressive level of compatability.
Sure, it's a bit limited as an OS by todays standards, but architecturally it's neat enough, and small enough and readable enough to be printed in its entirety in the appendix of a book which describes the theory behind it. So you could think of the first half of the Minix book as one enormous meta-comment for the rest of the code, perhaps.
It's nice, clean, traditional C style, too.
From that perspective, the Unix of the Lyons book is pretty readable too.
For something non-C, the source of the SmallEiffel compiler and it's libraries (all in Eiffel of course) is a pretty nice read too. CVSup (in Modula-3) is nice. Read lots of things, in lots of different languages. Some languages seem to lend themselves to clarity of expression a little more than C or C++ do. I don't think I've ever seen C++ code that was beautiful to read.