I agree that 90% of people who use databases would really be better off with simple text files or an in-memory server... SQL is overkill for shopping lists and username lists, though it certainly makes sense for high-end, high-performance stuff.
ReiserFS is trying to become a database. The first step was making ReiserFS v3 perform well on small files. (the idea is to store tree-like/XML-ish data in a directory structure where each file contains only a few bytes of data). Last I heard, ReiserFS v4 was moving towards a full transaction API that will allow atomic batch transactions on more than one file in a single system call. (aside from the space overhead problems inherent with storing tiny amounts of data in each file, most current filesystems don't allow atomic transactions that involve more than one write to one file...)
Holy cow, they fixed the horrid fonts, which was the only complaint I had last time... (I still hope they double-buffer everything so it doesn't flicker like most Linux GUIs though)... Wow - finally a Linux desktop that looks slick and professional... (no offense to GNOME and KDE - but I always found them somewhat sub-par compared to good old explorer.exe).
The cure for window jumpiness during moving and resizing is to force the window manager to be synchronous with the client. ("synchronous" meaning that the window manager should wait for the client to catch up before changing the window again). Currently they are not synchronized, which means the client struggles to draw itself while the window moves around it. This could be fixed with a simple window manager protocol, no need to change X.
Of course, moving the window manager into either the client or the server is probably a good thing to do also.
One feature that would put XFree way ahead of Windows would be synching the server's event loop with the vertical retrace. Currently XFree triggers event handling on keyboard or mouse interrupts, which may occur more than once per monitor refresh, so a lot of effort is wasted drawing things and then drawing them again during a single refresh. (also, XFree does appear to drop mouse interrupts once in a while, which contributes to the "sticky" or "jerky" feeling of the mouse in X, as compared to glass-smooth like Win32)
A sack full of 27 200GB hard disks (or 1200 DVD-Rs) sent on a twelve-hour flight would also equal the claimed 1 Gbit/sec transmission rate... A couple cargo pallets of hard disks would blow it away:).
This is sort of happnening now... Most juniors and seniors at Cornell live near but outside campus, and use Time Warner Road Runner or Lightlink DSL for internet access, instead of the university network.
Of course, Cornell's own network is much, much faster than Road Runner or DSL in Ithaca...
LOL funny you mention that - a few days ago I almost trashed my own RAID-5 with an errant 'rm -rf'. Luckily I killed rm before it deleted anything critical:)
It sounds cool to have the US govt leaning on vendors to write patches, but I have a feeling that if this becomes the norm, vendors will just push DHS for longer and longer lead times. The article indicates this particular bug was known since January. Two months is a pretty long time to wait for patches!
And this is just DHS's "first test" - I imagine after they build up a cozy relationship with the major security-problem vendors (i.e. Microsoft), they might not even disclose any known flaws until patches come out (i.e. months to "never").
Remember that government officials will probably listen a lot more attentively to "captains of industry" (i.e. MS) than "those unwashed hippy hackers" (i.e. the open-source community).
I agree that a live mirror is perfect for short-term redundancy, given the low cost of IDE storage. However, I don't want to rely on "spinning platters" for long-term data security - aside from the danger of a sudden lightning strike or other electrical disaster taking everything out at once, mechanical media have all too finite lifetimes.
Say you are working on a comp in your compositing software, and you notice one of the objects in a 3D element is in the wrong place. Do you *really* want to open up Maya, fix the object, queue the scene for re-rendering, and re-load the new frames into the compositing system? Wouldn't it be easier if you could just "grab" the object and move it without leaving the compositor? The only reason we can't do this today is the extremely poor state of inter-app communication and automation. In the long term a fully-integrated environment is IMHO a much more ideal solution than separate applications.
It's sort of like being in a machine shop, where you take the thing you're working on to a drill press, then to a table saw, and maybe then to a lathe. Your primary concern is where in the shop these tools are... vs. say repairing something really small at a workbench, where you think more about the item you're working on, and just grab whatever hand tool is needed at the moment.
I would say that theoretically, in the long term, a "workbench" approach is better than a "work shop" appraoch. The major practical issue with this today is the poor communication between major applications. (e.g. imagine if a texture you were painting in Photoshop showed up *immediately* on the model in your 3D software, with no need to save and re-load between changes - this would be a first step in moving towards a "workbench" - look at Maya's Paint Effects, for instance...)
Re:Let the flames begin ... and ignore them.
on
XFree86 4.3.0 Released
·
· Score: 2, Insightful
All Unix GUI programs use X for the same reasons that (almost) all businesses use Microsoft Word...
There could be a serious advantage to audio cues though - imagine a modern debugging environment that played a sound every time [data was read from a file / a mutex was taken / a syscall was made ]. Since the ear works so differently from the eye, it might reveal patterns that would otherwise be very hard to pick up.
I once saw a link to a 'ps'/network status monitor that played forest sounds - e.g. a bird sings for each outgoing email, crickets chirp during a download, etc... If everything goes silent at once, it means you have a network problem:)
AFAIK interferometry increases resolution, but it doesn't let you detect signals fainter than any one of the telescopes could individually. And in this case it's the radiation-gathering that's important, not resolution... (I think)
Hmm... Inside a hollow sphere, the net gravitational field is zero. So if the museum were relatively sphere-shaped and mostly hollow inside, it wouldn't disturb the path of the probe that much.
True, dat... MS windows that have the tab also must have a status bar. (Mozilla could implement one just by moving the padlock icon over a bit, hmm...)
I agree that it's annoying when you can't move a "hung" window, but that's because of one really nice thing about the MS window manager - window movement and resizing are synchronous, rather than asynchronous as in X. This is why you see much less tearing/jumpiness of window contents in Windows compared to X. (the MS window manager could allow "hung" windows to be moved if it treated them specially, e.g. with a timeout that detects when the message loop isn't responding)
I don't mean just the window border, I mean the extra little tab (maybe 10x10 pixels) that cuts diagonally from upper-right to lower-left. The tab has 3 little diagonal ridges on it. Usually you see these at the extreme right-hand side of the status bar at the bottom of a Microsoft Window. They provide an extra-large target area for resizing the window; without them you can only resize by hitting the 2- or 3-pixel wide window border.
Make your software as configurable as you want, I don't care, but PLEASE make sure the default settings are reasonable.
If I can just pick up a new program and start working without configuring it first, great. If I'm a hardcore user and want to customize things a bit, I can do that too.
But please don't use configuration options as a way to avoid hard design decisions. ("is it better to list foobars in one window or two? I don't know, let's make it an option!").
I'd like to see software that reports back to the developers how it's been configured. This way they can pick up configuration trends; e.g. if every power user wants a one-window foobar listing, maybe it should become the default...
This technique was extremely effective for the MS Excel developers; a few years ago they were shocked to discover that how users used the program was completely different from their mental image - the developers thought most people would use Excel for advanced financial calculations, when instead most people used it for simple stuff like shopping lists and line graphs - they took advantage of this discovery to hammer on the features that people really used. (no, normal copies of MS Excel don't report on your activities, just special beta-test ones:)
My objection to most themes isn't the "learnability" problem, it's just plain masochistic design. e.g. every cool-looking Linux desktop theme I've otherwise liked uses teensy tiny little scrollbars and window titlebar buttons. Maybe a hyperactive eight-year-old with laser vision can handle those, but I sure can't. (what were the GTK guys thinking when they allowed scrollbar tabs to become one-pixel-tall targets in a large document?).
Actually my biggest complaint against Linux windowing systems in general is the lack of the little Microsoft-style diagonal resize tab in the lower-right-hand corner of most windows. I find it very difficult to "manage" windows without those handy little grabby things.
On Linux I'm using a 4Dwm theme that looks like a throwback to the 80's, but at least it's got nice thick window borders and buttons that I don't need a magnifying glass to see.
I don't think there is a "moral right" either way - neither users nor developers should be forced (by law) to fix bugs. The responsibility can be allocated by contract: when you buy a software package it should clearly state whether or not bug fixes are included in the purchase price. In fact you could have two different price points: "Microsoft Word As-Is" for $299 and "Microsoft Word Plus Bugfixes" for $499. (support contracts are another way of setting this up).
The problem is that most consumer-level software is pretty ambiguous about who carries the cost of bug fixes. Or rather, the license itself is clear (vendor not liable for any bugs whatsoever), but there is a wide-spread expectation that patches will be released "for free". A lot of computer gamers get burned this way - it's normal practice for game companies to release several free patches to fix problems that crop up, but when a vendor doesn't release patches, you have no recourse against them. (other than not buying future products from that vendor - but how many people seriously stopped buying e.g. EA games after Battlefield 1942?)
dietlibc. It's a very cool drop-in replacement libc that is orders of manitude smaller (and somewhat faster) than GNU glibc. It's also GPL by choice of the author.
And what about your HDR to 8-bit conversion code?? It looks to me like it's GPL only, yes? (interesting, in the copyright header it refers to BOTH "the GNU General Public License" and "the GNU Library General Public License" - which is it?)
"We don't do a new version to fix bugs. We don't. Not enough people would buy it. You can take a hundred people using Microsoft Word. Call them up and say 'Would you buy a new version because of bugs?' You won't get a single person to say they'd buy a new version because of bugs."
No matter how much we SAY we hate software bugs, we still go out and buy software that we know probably contains them. And we are not really that willing to pay for bug fixes. Not because they "should be free" - we already paid for the software, so there is no reason for the vendor to put effort into releasing fixes (unless we're on a support contract or something). If we software consumers really want to make a point that bugs will not be tolerated, then we have to STOP paying for buggy software. And if we still hand over the cash, with full knowledge of potential bugs, then by the economic principle of revealed preference, the vendor is right - it's not worth it to fix bugs.
One might argue that direct function calls are better because they allow explicit checking of types and function signatures (by the compiler) and invariants (at function entry points). Just passing structs around is easier on programmers, but can lead to very hard-to-find bugs if somebody makes a mistake somewhere (imagine a large C program where every function took one void* argument).
A good example of this: Why didn't the recording industry stand up and take notice of online copyright infringement until Napster came out, even though people had been trading MP3s over IRC for years? There was nothing fundamentally different in the technology of Napster and the old IRC/FTP combo. The key difference was that Napster wrapped it all up into one easy-to-use package, which increased the potential user base by several orders of magnitude. (you have to be pretty geeky to work IRC and FTP together, but just about anyone with Windows and an internet connection can figure out Napster)
Up until 2-3 years ago the visual effects industry was firmly (though reluctantly) set on NT as the succesor to IRIX. This had nothing to do with the relative merits of NT; it was mostly because SGI had started falling seriously behind PCs in terms of raw CPU power and even OpenGL speed. The high-end studios that rely on lots of custom software definitely dragged their heels around this, since it is so difficult to port everything from a UNIX environment to Win32. Nonetheless the shift appeared to be inevitable; SGI's desktop machines could hardly even hold up to cheap Celerons (much less DEC Alphas) with 3DLabs or NVIDIA cards*.
Then Linux appeared like some grand accident or surprise mutation. The studios suddently had an alternative to the death-march towards NT. All the power of the PC, in a familiar UNIX environment, was too good of a deal to pass up. And now you see the entire industry adopting Linux as strongly as it adopted IRIX. There are of course still gaps to fill in day-to-day software for graphics work (like a fast 2D flipbook player or a media codec library or - dare I say it - Photoshop), but it's clear that Linux is here to stay.
* I acknowledge the inter-CPU bandwidth and scalability advantages of SGI hardware, but keep in mind that visual effects work leans much more heavily on individual CPU speed and to a lesser extent OpenGL.
Slashdot Mirror
I agree that 90% of people who use databases would really be better off with simple text files or an in-memory server... SQL is overkill for shopping lists and username lists, though it certainly makes sense for high-end, high-performance stuff.
ReiserFS is trying to become a database. The first step was making ReiserFS v3 perform well on small files. (the idea is to store tree-like/XML-ish data in a directory structure where each file contains only a few bytes of data). Last I heard, ReiserFS v4 was moving towards a full transaction API that will allow atomic batch transactions on more than one file in a single system call. (aside from the space overhead problems inherent with storing tiny amounts of data in each file, most current filesystems don't allow atomic transactions that involve more than one write to one file...)
Holy cow, they fixed the horrid fonts, which was the only complaint I had last time... (I still hope they double-buffer everything so it doesn't flicker like most Linux GUIs though)... Wow - finally a Linux desktop that looks slick and professional... (no offense to GNOME and KDE - but I always found them somewhat sub-par compared to good old explorer.exe).
...and take a speed hit as all the mundane programs like 'cat' and 'ls' now have double the memory footprint...
64-bit code should be applied selectively, only to the prorgams that actually need the extra address space.
The cure for window jumpiness during moving and resizing is to force the window manager to be synchronous with the client. ("synchronous" meaning that the window manager should wait for the client to catch up before changing the window again). Currently they are not synchronized, which means the client struggles to draw itself while the window moves around it. This could be fixed with a simple window manager protocol, no need to change X.
Of course, moving the window manager into either the client or the server is probably a good thing to do also.
One feature that would put XFree way ahead of Windows would be synching the server's event loop with the vertical retrace. Currently XFree triggers event handling on keyboard or mouse interrupts, which may occur more than once per monitor refresh, so a lot of effort is wasted drawing things and then drawing them again during a single refresh. (also, XFree does appear to drop mouse interrupts once in a while, which contributes to the "sticky" or "jerky" feeling of the mouse in X, as compared to glass-smooth like Win32)
A sack full of 27 200GB hard disks (or 1200 DVD-Rs) sent on a twelve-hour flight would also equal the claimed 1 Gbit/sec transmission rate... A couple cargo pallets of hard disks would blow it away :).
:(
The ping time would be about 43200000ms though
This is sort of happnening now... Most juniors and seniors at Cornell live near but outside campus, and use Time Warner Road Runner or Lightlink DSL for internet access, instead of the university network.
Of course, Cornell's own network is much, much faster than Road Runner or DSL in Ithaca...
LOL funny you mention that - a few days ago I almost trashed my own RAID-5 with an errant 'rm -rf'. Luckily I killed rm before it deleted anything critical :)
It sounds cool to have the US govt leaning on vendors to write patches, but I have a feeling that if this becomes the norm, vendors will just push DHS for longer and longer lead times. The article indicates this particular bug was known since January. Two months is a pretty long time to wait for patches!
And this is just DHS's "first test" - I imagine after they build up a cozy relationship with the major security-problem vendors (i.e. Microsoft), they might not even disclose any known flaws until patches come out (i.e. months to "never").
Remember that government officials will probably listen a lot more attentively to "captains of industry" (i.e. MS) than "those unwashed hippy hackers" (i.e. the open-source community).
I agree that a live mirror is perfect for short-term redundancy, given the low cost of IDE storage. However, I don't want to rely on "spinning platters" for long-term data security - aside from the danger of a sudden lightning strike or other electrical disaster taking everything out at once, mechanical media have all too finite lifetimes.
(replying to add another example)
Say you are working on a comp in your compositing software, and you notice one of the objects in a 3D element is in the wrong place. Do you *really* want to open up Maya, fix the object, queue the scene for re-rendering, and re-load the new frames into the compositing system? Wouldn't it be easier if you could just "grab" the object and move it without leaving the compositor? The only reason we can't do this today is the extremely poor state of inter-app communication and automation. In the long term a fully-integrated environment is IMHO a much more ideal solution than separate applications.
It's sort of like being in a machine shop, where you take the thing you're working on to a drill press, then to a table saw, and maybe then to a lathe. Your primary concern is where in the shop these tools are... vs. say repairing something really small at a workbench, where you think more about the item you're working on, and just grab whatever hand tool is needed at the moment.
I would say that theoretically, in the long term, a "workbench" approach is better than a "work shop" appraoch. The major practical issue with this today is the poor communication between major applications. (e.g. imagine if a texture you were painting in Photoshop showed up *immediately* on the model in your 3D software, with no need to save and re-load between changes - this would be a first step in moving towards a "workbench" - look at Maya's Paint Effects, for instance...)
All Unix GUI programs use X for the same reasons that (almost) all businesses use Microsoft Word...
There could be a serious advantage to audio cues though - imagine a modern debugging environment that played a sound every time [data was read from a file / a mutex was taken / a syscall was made ]. Since the ear works so differently from the eye, it might reveal patterns that would otherwise be very hard to pick up.
:)
I once saw a link to a 'ps'/network status monitor that played forest sounds - e.g. a bird sings for each outgoing email, crickets chirp during a download, etc... If everything goes silent at once, it means you have a network problem
AFAIK interferometry increases resolution, but it doesn't let you detect signals fainter than any one of the telescopes could individually. And in this case it's the radiation-gathering that's important, not resolution... (I think)
Hmm... Inside a hollow sphere, the net gravitational field is zero. So if the museum were relatively sphere-shaped and mostly hollow inside, it wouldn't disturb the path of the probe that much.
True, dat... MS windows that have the tab also must have a status bar. (Mozilla could implement one just by moving the padlock icon over a bit, hmm...)
I agree that it's annoying when you can't move a "hung" window, but that's because of one really nice thing about the MS window manager - window movement and resizing are synchronous, rather than asynchronous as in X. This is why you see much less tearing/jumpiness of window contents in Windows compared to X. (the MS window manager could allow "hung" windows to be moved if it treated them specially, e.g. with a timeout that detects when the message loop isn't responding)
I don't mean just the window border, I mean the extra little tab (maybe 10x10 pixels) that cuts diagonally from upper-right to lower-left. The tab has 3 little diagonal ridges on it. Usually you see these at the extreme right-hand side of the status bar at the bottom of a Microsoft Window. They provide an extra-large target area for resizing the window; without them you can only resize by hitting the 2- or 3-pixel wide window border.
Make your software as configurable as you want, I don't care, but PLEASE make sure the default settings are reasonable.
:)
If I can just pick up a new program and start working without configuring it first, great. If I'm a hardcore user and want to customize things a bit, I can do that too.
But please don't use configuration options as a way to avoid hard design decisions. ("is it better to list foobars in one window or two? I don't know, let's make it an option!").
I'd like to see software that reports back to the developers how it's been configured. This way they can pick up configuration trends; e.g. if every power user wants a one-window foobar listing, maybe it should become the default...
This technique was extremely effective for the MS Excel developers; a few years ago they were shocked to discover that how users used the program was completely different from their mental image - the developers thought most people would use Excel for advanced financial calculations, when instead most people used it for simple stuff like shopping lists and line graphs - they took advantage of this discovery to hammer on the features that people really used. (no, normal copies of MS Excel don't report on your activities, just special beta-test ones
My objection to most themes isn't the "learnability" problem, it's just plain masochistic design. e.g. every cool-looking Linux desktop theme I've otherwise liked uses teensy tiny little scrollbars and window titlebar buttons. Maybe a hyperactive eight-year-old with laser vision can handle those, but I sure can't. (what were the GTK guys thinking when they allowed scrollbar tabs to become one-pixel-tall targets in a large document?).
Actually my biggest complaint against Linux windowing systems in general is the lack of the little Microsoft-style diagonal resize tab in the lower-right-hand corner of most windows. I find it very difficult to "manage" windows without those handy little grabby things.
On Linux I'm using a 4Dwm theme that looks like a throwback to the 80's, but at least it's got nice thick window borders and buttons that I don't need a magnifying glass to see.
I don't think there is a "moral right" either way - neither users nor developers should be forced (by law) to fix bugs. The responsibility can be allocated by contract: when you buy a software package it should clearly state whether or not bug fixes are included in the purchase price. In fact you could have two different price points: "Microsoft Word As-Is" for $299 and "Microsoft Word Plus Bugfixes" for $499. (support contracts are another way of setting this up).
The problem is that most consumer-level software is pretty ambiguous about who carries the cost of bug fixes. Or rather, the license itself is clear (vendor not liable for any bugs whatsoever), but there is a wide-spread expectation that patches will be released "for free". A lot of computer gamers get burned this way - it's normal practice for game companies to release several free patches to fix problems that crop up, but when a vendor doesn't release patches, you have no recourse against them. (other than not buying future products from that vendor - but how many people seriously stopped buying e.g. EA games after Battlefield 1942?)
dietlibc. It's a very cool drop-in replacement libc that is orders of manitude smaller (and somewhat faster) than GNU glibc. It's also GPL by choice of the author.
And what about your HDR to 8-bit conversion code?? It looks to me like it's GPL only, yes? (interesting, in the copyright header it refers to BOTH "the GNU General Public License" and "the GNU Library General Public License" - which is it?)
This, I think, is the key:
"We don't do a new version to fix bugs. We don't. Not enough people would buy it. You can take a hundred people using Microsoft Word. Call them up and say 'Would you buy a new version because of bugs?' You won't get a single person to say they'd buy a new version because of bugs."
No matter how much we SAY we hate software bugs, we still go out and buy software that we know probably contains them. And we are not really that willing to pay for bug fixes. Not because they "should be free" - we already paid for the software, so there is no reason for the vendor to put effort into releasing fixes (unless we're on a support contract or something). If we software consumers really want to make a point that bugs will not be tolerated, then we have to STOP paying for buggy software. And if we still hand over the cash, with full knowledge of potential bugs, then by the economic principle of revealed preference, the vendor is right - it's not worth it to fix bugs.
One might argue that direct function calls are better because they allow explicit checking of types and function signatures (by the compiler) and invariants (at function entry points). Just passing structs around is easier on programmers, but can lead to very hard-to-find bugs if somebody makes a mistake somewhere (imagine a large C program where every function took one void* argument).
A good example of this: Why didn't the recording industry stand up and take notice of online copyright infringement until Napster came out, even though people had been trading MP3s over IRC for years? There was nothing fundamentally different in the technology of Napster and the old IRC/FTP combo. The key difference was that Napster wrapped it all up into one easy-to-use package, which increased the potential user base by several orders of magnitude. (you have to be pretty geeky to work IRC and FTP together, but just about anyone with Windows and an internet connection can figure out Napster)
Up until 2-3 years ago the visual effects industry was firmly (though reluctantly) set on NT as the succesor to IRIX. This had nothing to do with the relative merits of NT; it was mostly because SGI had started falling seriously behind PCs in terms of raw CPU power and even OpenGL speed. The high-end studios that rely on lots of custom software definitely dragged their heels around this, since it is so difficult to port everything from a UNIX environment to Win32. Nonetheless the shift appeared to be inevitable; SGI's desktop machines could hardly even hold up to cheap Celerons (much less DEC Alphas) with 3DLabs or NVIDIA cards*.
Then Linux appeared like some grand accident or surprise mutation. The studios suddently had an alternative to the death-march towards NT. All the power of the PC, in a familiar UNIX environment, was too good of a deal to pass up. And now you see the entire industry adopting Linux as strongly as it adopted IRIX. There are of course still gaps to fill in day-to-day software for graphics work (like a fast 2D flipbook player or a media codec library or - dare I say it - Photoshop), but it's clear that Linux is here to stay.
* I acknowledge the inter-CPU bandwidth and scalability advantages of SGI hardware, but keep in mind that visual effects work leans much more heavily on individual CPU speed and to a lesser extent OpenGL.