Incidentally, I've wondered . . . when you sign up for this thing, do you get a permanent account, or is it something where it lasts like two weeks and then you have to sign up again?
It sure would be useful for test-building stuff, at least before SourceForge gets them Alphas . . .
The site sounds like a great idea! It'd be especially cool if it could provide a means of creating direct feedback loops between good UI designers and coders, and also a forum on next-gen interface ideas/possibilities. I'll sure check it out when it opens.
There's just one problem, however . . . when I submit my name/e-mail to the announce list, Zope sends me a login/password dialog. Authorization fails. There's a bug rattling somewhere in there:->
Well, since the article seems to be a rerun, and we're on the subject of better user interfaces (or lack thereof) . . .
I've been thinking of some alternate user-interface ideas, and one possibility I picked up from reading Tog (or was is Nielson?) was that of using "official icons"-- namely, ISO standard international symbols-- as a good, consistent visual supplement to the interface. (These symbols, I believe, are seen a lot in European countries. I don't think they're used a whole lot in the U.S.)
Problem is, I've looked everywhere, and I can't find any references for such symbols. The closest I've come to is this site detailing IEC 417 (which is why e.g. the "Play" and "Pause" buttons on media players are all marked the same), but that's about it. The ISO site helped, but not by much (their search engine sucks rocks).
So, would anyone here know of any links detailing said standard international symbols, or at least some relevant ISO numbers?
(P.S.: I already have ISO 7000 - "Graphical symbols for use on equipment")
Nahhh . . . Windows systems are easy to come by, and if you really wanted to build Win32 binaries, you can always grab Mingw32/Lccwin/etc. and use that. I don't think there are too many folks interested in supporting Win32, however. (We'll have to see-- things might change when the Windows-capable GTK+ 1.4 comes out)
As for Microsoft contributing anything: you have got to be kidding. Those boys not only don't have to encourage anyone to write stuff for their platform, they happily charge an arm and a leg for VC++ and all the MSDN program junk....
Write according to the Unix standards. Use POSIX and avoid Linux-only kernel calls. Use standard C and avoid the extensions in glibc.
Agreed. Definitely worthwhile advice. But keep in mind that a lot of systems don't quite measure up to the standard. And that's where autoconf comes in.
E.g. older libc5 Linux systems don't have strtok_r() -- autoconf can detect this, tell automake to build strtok_r.c, and add strtok_r.o to @LIBOBJS@. Some systems don't quite agree on what the argument types to select() are -- autoconf can determine those, and put them into handy macros you can use for casting. Etc., etc.
The point being: Yes, write your code The Right Way(tm). Anything less is a hack. But use autoconf so that folks with less-than-perfect operating systems can compile it.
Because even if VA is doing this to help move more hardware, they still deserve the kudos. The compile farm (even if all x86) will allow developers to catch subtle bugs brought on by distribution quirks, as well as allow them to create RPM's *and* DEB's easily from one spot. It's a win-win situation, and one of those wins is ours.
But I definitely agree that other architectures in the farm, including a plethora of non-free Unices, will be a boon to everyone. Each non-GNU system has its own eccentricities and bits of brain-deadness; testing code in such enviroments provides first-rate insight into its robustness and portability. The disadvantage to Linux/gcc is simply the sheer quality and capability of the platform. When you write for it, you're writing for a better Unix than "Unix" itself. (Hence you see all these apps that won't build on commercial Unices, and-- in the worse cases-- even *BSD).
I know when I compile stuff under IRIX (for example), the compiler gives me warnings I don't see under gcc, some header files (libintl.h for one) are nowhere to be found, the paths for X binaries and libraries are completely different, etc. You have to be aware of things like that to write solid configure scripts, and design the code accordingly. Myself, I'm lucky enough to have access to computer labs lined with Sun and SGI workstations. But many developers don't. And even I can't build/test anything on HP/UX, Tru64, AIX, etc. MIT doesn't support those {:-(
What you're saying, however-- having each and every Linux/BSD/etc. on each and every platform that they runs on-- is not worthwhile. Sure, that covers a lot of possible end-user setups, but keep in mind:
Do you want to test and build for 30+ slightly different OS/platform combos?
Heck, forget using; who here wants to administrate that??
Is it even necessary? Sure, Linux distros have some incompatibilities, but IT'S NOT THAT BAD!!! This isn't UNIX, after all...
In the end, when you're building something with gcc, the platform doesn't make all that much of a difference anyway. The GNU libraries are well-designed, and work around a lot of those issues. (Endianness isn't even that much of a problem, if you code things the right way)
IMHO, it would be much more sensible to add in a group of machines widely spread across the spectrum of platforms. Corner cases, if you will. If your app can build on three weird platforms, it'll probably build on a fourth. But you can write an app that will compile on every Linux distro in existence, yet fail horribly on any commercial Unix system you can name.
And let me emphasis the need to shun gcc and test using vendor-native compilers. If you're on a non-x86 platform, and gcc isn't the only compiler available, you have to cater to people who don't have gcc installed. And more important, the compiler warning messages tend to be a lot more interesting, simply because they're different from gcc's (and gcc's are almost always the same)
But putting an S/390 into the farm is overkill. Far and beyond. Those machines are waaaaay too expensive for something like this. (Seriously; the only thing to top it would be a Cray supercomputer!)
X can be sent through an encrypted ssh tunnel. Security is no more a concern than for the shell access (terminal line) itself.
What would pose some problems, however, is bandwidth. I don't doubt VA has reams of it, but several hundred simulataneous X sessions (particularly of fancy Gnome/KDE apps with heavy high-color graphics) could bring even a.com's netlink to its knees.
There will probably have to be a bandwidth policy, to keep things working smoothly. It would be completely reasonable.
(And as an aside, to VA: THANKS!!! The Compile Farm is an excellent idea! I look forward to testing and building my apps there. HP/UX and Alpha binaries, here I come!)
Another problem is that some software packages assume that "make install" will always be executed by root and include things like "install -o root" which will fail for non-root users. This is the most common reason for source RPMs which cannot be built by a non-root user.
Anything that uses -o root in the install is broken. That means I can't install things to e.g. a home directory. (There might be exceptions to this rule, e.g. dpkg, but those are very few and far between)
The usual problem with SRPM's, however, are install -o user commands written directly into the.spec file (not the Makefile). I keep a nice, big stick labeled "%defattr" for folks who write those:P
If I recall correctly, AT&T holds a patent on that. The original bzip used arithmetic encoding, but then the patent came to the attention of the author. He pulled the program, redesigned the algorithm, and released it as bzip2.
Arithmetic encoding is no big deal, however. The author has stated (I forgot where) that it only gives you a 1-2% improvement in compression ratio. I think it also runs faster, but only by a similarly small margin.
One thing mentioned on the Quesa maillist is that this may allow for more resources to bear in the completion of the library. Progress on Quesa hasn't been too bad (although you wouldn't guess it from the rather infrequent releases-- there are just a small cadre of developers working on it), but a few hard snags still remain before the current goal of QD3D 1.6 compatibility (e.g. NURBS equations, according to Joe Strout)
By the way, for anyone not familiar with Quesa, check it out. It's an incredibly well-designed 3D scene graph API, roughly the equivalent of Inventor. (Or is it Performer? I keep getting those two mixed up). Apple dropped support for it in OS X (they went OpenGL-only), so right now the API is in that same eerie twilight zone as the old OPENSTEP API, where you have this very clean, well-architectured standard basically abandoned by its parent company. (The cool thing being, of course, that future development of such a standard falls into the hands of "the community," a la GNUStep)
I've heard wonders of the elegance of this API. Definitely superior to Inventor. (or Performer). And the nice thing about Quesa is that the implementation is sweet-- the structure, even the commenting is beautifully done. Quesa is going to be one hell of a graphics library when it is finished. I'm hoping it will become the cross-platform standard 3D scene graph layer, much as OpenGL already has for low-level 3D. I'd be hard-pressed to name anything better.
Bezos does have a point, however, when he says that if Amazon wouldn't have done it, someone else would have and destroyed them with it.
If Bezos had simply obtained the patent, and kept it in the company's portfolio for defense, then he would have some merit in that point. But he took B&N to court, and stopped them from using the "1-click" system. He used that patent offensively, not defensively. (And as far as was mentioned, B&N wasn't throwing Amazon any legal punches before Amazon did).
Bezos talks a reasonable talk, but his company's doing exactly what he fears others would do to him. Net negative gain, folks.
The main benefit to having everything in XML is that it gives you a standard means of modifying the config files. You could load up anything into, say, Conglomerate, and edit away. (Emacs/vi will work too, although XML is less plaintext-editor friendly). But more importantly, things like linuxconf and your typical next-gen admin tool will finally have a clean, standardized way of parsing and modifying those files, rather than the black magic being used at present. It's much easier to attain that you-can-use-a-text-editor-or-the-gui-tools-equally -well balance with XML, regardless of the number of particular DTD's involved.
I've always thought a good form factor for a handheld would be something along the lines of the medical tricorder device from Star Trek:TNG.
Basically, imagine something only slightly larger than a Pilot (but smaller than the z50 or these other "micro laptops"), with a thick clamshell design that evenly distributes the weight between the two halves.
The reason this would be cool is you could build it rugged as hell-- think a "metal with rubber trim" exterior-- and it would be perfectly suited for clipping onto a belt or whatnot. Just like a tape measure.
It would sure beat these super-delicate quarter-inch-thick Pilots and their flimsy plastic screen guards (well, as long as you don't want to slip it into that shirt pocket...:-)
I agree with what you're saying. In this debate, however, the equality has been brought up a few times ("she pressed Enter and immediately a picture of a nude female appeared before her...")
However, I think the best solution is to allow children to gain a greater maturity regarding such matters earlier in life. When you saw that hard-core stuff, it disgusted you, but it didn't mess you up. You kept on living your life just as well. (I hope:-) There's no reason why a five- or eight-year old couldn't have as resilient a facility, given proper nurture.
I once saw a video about young schoolboys in China. They play games, they do their studies just like any other kids their age, but what really impressed me was their lunch hour. Their school cafeteria is entirely run by them-- not a single person over ten years old. And that includes the people behind the food racks, serving up the dishes. And everything moves along with perfect order. And they leave the cafeteria perfectly spotless when they finish.
Compare this to an American classroom, where most of the teacher's time is spent simply keeping her students under control.
The lesson being, children will be as responsible (or irresponsible) as you make them to be. Not to say this can be carried to an extreme degree, of course-- but that, as a whole, our society has greatly underestimated its youth.
To begin with, we need to get this idea out of our heads that a kid who accidentally looks at a nude human being will be emotionally or socially injured in some way.
The only reason this is such a big deal is because of the long tradition of Puritanical/conservative/whatever values in this country that associate sinfulness/evil with the nude human form. This is completely artificial, and the sooner that sentiment is gone, the better.
If you want to talk about something that young kids really shouldn't see, how about some of the horror films to come out of the Holocaust? Who here hasn't seen, say, that grainy black-and-white film clip showing a bulldozer pushing a huge pile of dead, emaciated bodies of Jewish victims into a shallow grave?
I saw that one a long time ago, I think when I was twelve, and it hit me pretty hard. If I had seen that when I was five or seven, it would probably have left a much stronger impression on me, to the point of being harmful. (As in, I'd have needed some serious counseling to be able to get on with my life).
But even then, the only reason seeing something should leave such a strong impression on a person (not just a young person) is that he/she is unprepared for it.
The heart of this whole problem is that we are giving children these incredibly sheltered lives, where sex is unknown to them until the two-digit age range, where racism and political realities are fuzzy concepts with no real-world relevance-- while, at the same time, mass media and the Internet are super-shotgunning that filtered worldview into Swiss cheese.
And there are two ways of reacting to that. Either you call for mass action to hold back the ocean of foreign thoughts, and ideas, and pictures coming in through the cable and telephone lines-- at this point, akin to commanding the tide not to come-- or you can push up the timetable of those "little talks" you've been preparing for your kids, by about five or six years. (Or more)
Children are learning about things a lot sooner than many people are expecting them to (and taking great pains that they do). Between valiantly fighting to keep the wool over their eyes, or telling them about such things earlier, I think the latter route is the better one.
(Not that I would tell my hypothetical four-year-old all about the Holocaust, but if she were to see some of those images, and come crying to me, I would sit down with her, and explain to her the whole sordid story. As well as why a great many people today go to a lot of effort to ensure such a thing will never happen again. This, as opposed to postponing the issue for a few years with, "No, no, that was just an old horror movie...")
I have to admit, mentioning that she was Japanese was a bit arbitrary. That did seem to make sense, as far as foreign exchanging went, but apparently not for other reasons:-]
All I really remember was that she was supposedly from the far East. Probably from one of the cities less ravaged by Westernism. (I can imagine some strong nudity taboos are implicit within the culture)
I have to agree with your sentiment. Sure enough, if you go to places like Europe or Asia, there is a lot less stigma attached to nudity. (Not that it's a totally normal thing there either, but at least no one goes AAAAAAAHHH!!! NEKKID PEOPLE!!!)
I once heard a (true) story about a female Japanese foreign exchange student, staying with an American family. One night, they all decided to go for a dip in the family jacuzzi. When this young woman came to join them, she was not wearing anything.
Obviously, this caused a bit of confusion. It basically ended with the father-type figure sitting down with her, and explaining how nudity has very strong sexual overtones, and therefore that modesty was an important thing to uphold.
Her response was something along the lines of, "But bathing is not sexual."
(If anyone knows the original source of this story, please chime in. There is considerable bitrot in the recollection above).
In any case, it was quite eye-opening. The sad part of all this is, the way nudity keeps on being such a Big Deal in our society is by people making a big deal about it. I mean, if parents would just sit down with their (pre-puberty) kids, and pull out a Play{boy,girl} magazine, and just explain what is pornography, why it's so popular, how it can be good, how it can be bad, etc. etc.-- it will become a non-issue. Kids will see a porn site, say "bah!", and keep right on surfing to the Pokemon site they were looking for. There's no reason why an 8-year old can't be as mature about such things as a 21-year old.
This was released just last month. It's LGPL'ed, built on OpenGL/GTK+, and while it lacks many features of the original fsn (and isn't even at 1.0 yet) it sports a slicker interface, and not one but two distinct approaches to visualizing the file system.
There have been some noises to making this into a Nautilus optional view mode, which would be pretty cool (since the program would then have a real file manager backend, and what with XFree4.0/DRI coming around the bend...)
Definitely. I'm not sure at what -On it happens, but at -O9 (with -Wall) you get the "variable might be used before initialization" warnings which are very helpful. (There might be a -Wsomething flag for it, but I never looked into those)
Seeing some of the other comments posted here, however, it seems -Wall isn't quite all it's cracked up to be. I'll have to dig through the gcc docs a little. (Not to mention cajole the boys at Cygnus to add a -Whit-me-with-everything-youve-got flag or something;-)
It's not that gcc lets through incorrect code, just that SGI's compiler is very good at pointing out quirks that could be potential problems. All warning-land stuff, of course.
Some niceties cc gets that gcc doesn't:
Variables that are assigned a value, but never used in an expression/function call
Static functions that aren't referenced by any other function (gcc does do this for variables, however)
Function arguments that aren't referenced (a bit nitpicky, but it's good to name them foo_unused or whatever)
Mixing of integer and enumerated types without (int) casts (annoying sometimes, 'specially when building GTK+ code, but hey, it doesn't hurt)
There are others, but alas, I don't have a big hairy codebase under development right now to give more examples:-( Most of the time, it's things that make you say "okay, no big deal, but I really should clean up that bit..."
To gcc's credit, it does do some pretty spiffy control-flow analysis with -O9 ("variable foo may be used before initialization", "statement is unreachable", etc.). But still, I don't consider a program done until I have an excuse for each and every warning given by SGI's compiler.
(Back to gcc, I'll have to try -W along with -Wall... that really turns up the analness? I'd use -ansi, except that it takes out nice things like inline functions and printf'ing long long ints)
I'm wondering, especially since they went the whole nine yards to release this under GPL-- will this be a new backend to gcc, or is it a whole new animal?
While I haven't had cause to complain about gcc's compiled-binary performance, I will go gaga if [SGI's compiler] has the same code-analysis capability as the IRIX cc. Having lint practically built right in is soooooo nice for debugging... if you can build it cleanly with -fullwarn, you can build it anywhere. (IMHO, gcc's greatest fault is that it's too damned lenient }:->
Part of the GNUstep project has a Display Postscript reimplementation, which isn't that different. Someone here posted in the last OSX article that DPDF is better because it doesn't need as advanced a rendering system to work (as PDF lacks the Turing-completeness of PS).
What I'm wondering, however, is if DPDF/Quartz can be (efficiently) made network-transparent. At least with DPS this is possible, and the flexibility of the protocol lets you do some neat things in that vein....
Interesting idea, but it would probably just be more efficient to combine the editor with xdvi (the engine, not the interface!) rather than gv... that way, you get rid of the PS/PDF stage, which (in your example) is an intermediate between the editor and the screen anyway.
Slashdot Mirror
Yup, it says it right there :-] (I didn't see anything about that the last time I was there, so I didn't bother checking this time)
So it's thirty days. I sure hope they don't mind, um, repeat customers <g>
Incidentally, I've wondered . . . when you sign up for this thing, do you get a permanent account, or is it something where it lasts like two weeks and then you have to sign up again?
It sure would be useful for test-building stuff, at least before SourceForge gets them Alphas . . .
The site sounds like a great idea! It'd be especially cool if it could provide a means of creating direct feedback loops between good UI designers and coders, and also a forum on next-gen interface ideas/possibilities. I'll sure check it out when it opens.
:->
There's just one problem, however . . . when I submit my name/e-mail to the announce list, Zope sends me a login/password dialog. Authorization fails. There's a bug rattling somewhere in there
Well, since the article seems to be a rerun, and we're on the subject of better user interfaces (or lack thereof) . . .
I've been thinking of some alternate user-interface ideas, and one possibility I picked up from reading Tog (or was is Nielson?) was that of using "official icons"-- namely, ISO standard international symbols-- as a good, consistent visual supplement to the interface. (These symbols, I believe, are seen a lot in European countries. I don't think they're used a whole lot in the U.S.)
Problem is, I've looked everywhere, and I can't find any references for such symbols. The closest I've come to is this site detailing IEC 417 (which is why e.g. the "Play" and "Pause" buttons on media players are all marked the same), but that's about it. The ISO site helped, but not by much (their search engine sucks rocks).
So, would anyone here know of any links detailing said standard international symbols, or at least some relevant ISO numbers?
(P.S.: I already have ISO 7000 - "Graphical symbols for use on equipment")
Nahhh . . . Windows systems are easy to come by, and if you really wanted to build Win32 binaries, you can always grab Mingw32/Lccwin/etc. and use that. I don't think there are too many folks interested in supporting Win32, however. (We'll have to see-- things might change when the Windows-capable GTK+ 1.4 comes out)
As for Microsoft contributing anything: you have got to be kidding. Those boys not only don't have to encourage anyone to write stuff for their platform, they happily charge an arm and a leg for VC++ and all the MSDN program junk....
E.g. older libc5 Linux systems don't have strtok_r() -- autoconf can detect this, tell automake to build strtok_r.c, and add strtok_r.o to @LIBOBJS@. Some systems don't quite agree on what the argument types to select() are -- autoconf can determine those, and put them into handy macros you can use for casting. Etc., etc.
The point being: Yes, write your code The Right Way(tm). Anything less is a hack. But use autoconf so that folks with less-than-perfect operating systems can compile it.
Because even if VA is doing this to help move more hardware, they still deserve the kudos. The compile farm (even if all x86) will allow developers to catch subtle bugs brought on by distribution quirks, as well as allow them to create RPM's *and* DEB's easily from one spot. It's a win-win situation, and one of those wins is ours.
But I definitely agree that other architectures in the farm, including a plethora of non-free Unices, will be a boon to everyone. Each non-GNU system has its own eccentricities and bits of brain-deadness; testing code in such enviroments provides first-rate insight into its robustness and portability. The disadvantage to Linux/gcc is simply the sheer quality and capability of the platform. When you write for it, you're writing for a better Unix than "Unix" itself. (Hence you see all these apps that won't build on commercial Unices, and-- in the worse cases-- even *BSD).
I know when I compile stuff under IRIX (for example), the compiler gives me warnings I don't see under gcc, some header files (libintl.h for one) are nowhere to be found, the paths for X binaries and libraries are completely different, etc. You have to be aware of things like that to write solid configure scripts, and design the code accordingly. Myself, I'm lucky enough to have access to computer labs lined with Sun and SGI workstations. But many developers don't. And even I can't build/test anything on HP/UX, Tru64, AIX, etc. MIT doesn't support those {:-(
What you're saying, however-- having each and every Linux/BSD/etc. on each and every platform that they runs on-- is not worthwhile. Sure, that covers a lot of possible end-user setups, but keep in mind:
- Do you want to test and build for 30+ slightly different OS/platform combos?
- Heck, forget using; who here wants to administrate that??
- Is it even necessary? Sure, Linux distros have some incompatibilities, but IT'S NOT THAT BAD!!! This isn't UNIX, after all...
- In the end, when you're building something with gcc, the platform doesn't make all that much of a difference anyway. The GNU libraries are well-designed, and work around a lot of those issues. (Endianness isn't even that much of a problem, if you code things the right way)
IMHO, it would be much more sensible to add in a group of machines widely spread across the spectrum of platforms. Corner cases, if you will. If your app can build on three weird platforms, it'll probably build on a fourth. But you can write an app that will compile on every Linux distro in existence, yet fail horribly on any commercial Unix system you can name.And let me emphasis the need to shun gcc and test using vendor-native compilers. If you're on a non-x86 platform, and gcc isn't the only compiler available, you have to cater to people who don't have gcc installed. And more important, the compiler warning messages tend to be a lot more interesting, simply because they're different from gcc's (and gcc's are almost always the same)
But putting an S/390 into the farm is overkill. Far and beyond. Those machines are waaaaay too expensive for something like this. (Seriously; the only thing to top it would be a Cray supercomputer!)
X can be sent through an encrypted ssh tunnel. Security is no more a concern than for the shell access (terminal line) itself.
.com's netlink to its knees.
What would pose some problems, however, is bandwidth. I don't doubt VA has reams of it, but several hundred simulataneous X sessions (particularly of fancy Gnome/KDE apps with heavy high-color graphics) could bring even a
There will probably have to be a bandwidth policy, to keep things working smoothly. It would be completely reasonable.
(And as an aside, to VA: THANKS!!! The Compile Farm is an excellent idea! I look forward to testing and building my apps there. HP/UX and Alpha binaries, here I come!)
Anything that uses -o root in the install is broken. That means I can't install things to e.g. a home directory. (There might be exceptions to this rule, e.g. dpkg, but those are very few and far between)
The usual problem with SRPM's, however, are install -o user commands written directly into the
If I recall correctly, AT&T holds a patent on that. The original bzip used arithmetic encoding, but then the patent came to the attention of the author. He pulled the program, redesigned the algorithm, and released it as bzip2.
Arithmetic encoding is no big deal, however. The author has stated (I forgot where) that it only gives you a 1-2% improvement in compression ratio. I think it also runs faster, but only by a similarly small margin.
One thing mentioned on the Quesa maillist is that this may allow for more resources to bear in the completion of the library. Progress on Quesa hasn't been too bad (although you wouldn't guess it from the rather infrequent releases-- there are just a small cadre of developers working on it), but a few hard snags still remain before the current goal of QD3D 1.6 compatibility (e.g. NURBS equations, according to Joe Strout)
By the way, for anyone not familiar with Quesa, check it out. It's an incredibly well-designed 3D scene graph API, roughly the equivalent of Inventor. (Or is it Performer? I keep getting those two mixed up). Apple dropped support for it in OS X (they went OpenGL-only), so right now the API is in that same eerie twilight zone as the old OPENSTEP API, where you have this very clean, well-architectured standard basically abandoned by its parent company. (The cool thing being, of course, that future development of such a standard falls into the hands of "the community," a la GNUStep)
I've heard wonders of the elegance of this API. Definitely superior to Inventor. (or Performer). And the nice thing about Quesa is that the implementation is sweet-- the structure, even the commenting is beautifully done. Quesa is going to be one hell of a graphics library when it is finished. I'm hoping it will become the cross-platform standard 3D scene graph layer, much as OpenGL already has for low-level 3D. I'd be hard-pressed to name anything better.
If Bezos had simply obtained the patent, and kept it in the company's portfolio for defense, then he would have some merit in that point. But he took B&N to court, and stopped them from using the "1-click" system. He used that patent offensively, not defensively. (And as far as was mentioned, B&N wasn't throwing Amazon any legal punches before Amazon did).
Bezos talks a reasonable talk, but his company's doing exactly what he fears others would do to him. Net negative gain, folks.
The main benefit to having everything in XML is that it gives you a standard means of modifying the config files. You could load up anything into, say, Conglomerate, and edit away. (Emacs/vi will work too, although XML is less plaintext-editor friendly). But more importantly, things like linuxconf and your typical next-gen admin tool will finally have a clean, standardized way of parsing and modifying those files, rather than the black magic being used at present. It's much easier to attain that you-can-use-a-text-editor-or-the-gui-tools-equally -well balance with XML, regardless of the number of particular DTD's involved.
I've always thought a good form factor for a handheld would be something along the lines of the medical tricorder device from Star Trek:TNG.
:-)
Basically, imagine something only slightly larger than a Pilot (but smaller than the z50 or these other "micro laptops"), with a thick clamshell design that evenly distributes the weight between the two halves.
The reason this would be cool is you could build it rugged as hell-- think a "metal with rubber trim" exterior-- and it would be perfectly suited for clipping onto a belt or whatnot. Just like a tape measure.
It would sure beat these super-delicate quarter-inch-thick Pilots and their flimsy plastic screen guards (well, as long as you don't want to slip it into that shirt pocket...
I agree with what you're saying. In this debate, however, the equality has been brought up a few times ("she pressed Enter and immediately a picture of a nude female appeared before her...")
:-) There's no reason why a five- or eight-year old couldn't have as resilient a facility, given proper nurture.
However, I think the best solution is to allow children to gain a greater maturity regarding such matters earlier in life. When you saw that hard-core stuff, it disgusted you, but it didn't mess you up. You kept on living your life just as well. (I hope
I once saw a video about young schoolboys in China. They play games, they do their studies just like any other kids their age, but what really impressed me was their lunch hour. Their school cafeteria is entirely run by them-- not a single person over ten years old. And that includes the people behind the food racks, serving up the dishes. And everything moves along with perfect order. And they leave the cafeteria perfectly spotless when they finish.
Compare this to an American classroom, where most of the teacher's time is spent simply keeping her students under control.
The lesson being, children will be as responsible (or irresponsible) as you make them to be. Not to say this can be carried to an extreme degree, of course-- but that, as a whole, our society has greatly underestimated its youth.
To begin with, we need to get this idea out of our heads that a kid who accidentally looks at a nude human being will be emotionally or socially injured in some way.
The only reason this is such a big deal is because of the long tradition of Puritanical/conservative/whatever values in this country that associate sinfulness/evil with the nude human form. This is completely artificial, and the sooner that sentiment is gone, the better.
If you want to talk about something that young kids really shouldn't see, how about some of the horror films to come out of the Holocaust? Who here hasn't seen, say, that grainy black-and-white film clip showing a bulldozer pushing a huge pile of dead, emaciated bodies of Jewish victims into a shallow grave?
I saw that one a long time ago, I think when I was twelve, and it hit me pretty hard. If I had seen that when I was five or seven, it would probably have left a much stronger impression on me, to the point of being harmful. (As in, I'd have needed some serious counseling to be able to get on with my life).
But even then, the only reason seeing something should leave such a strong impression on a person (not just a young person) is that he/she is unprepared for it.
The heart of this whole problem is that we are giving children these incredibly sheltered lives, where sex is unknown to them until the two-digit age range, where racism and political realities are fuzzy concepts with no real-world relevance-- while, at the same time, mass media and the Internet are super-shotgunning that filtered worldview into Swiss cheese.
And there are two ways of reacting to that. Either you call for mass action to hold back the ocean of foreign thoughts, and ideas, and pictures coming in through the cable and telephone lines-- at this point, akin to commanding the tide not to come-- or you can push up the timetable of those "little talks" you've been preparing for your kids, by about five or six years. (Or more)
Children are learning about things a lot sooner than many people are expecting them to (and taking great pains that they do). Between valiantly fighting to keep the wool over their eyes, or telling them about such things earlier, I think the latter route is the better one.
(Not that I would tell my hypothetical four-year-old all about the Holocaust, but if she were to see some of those images, and come crying to me, I would sit down with her, and explain to her the whole sordid story. As well as why a great many people today go to a lot of effort to ensure such a thing will never happen again. This, as opposed to postponing the issue for a few years with, "No, no, that was just an old horror movie...")
I have to admit, mentioning that she was Japanese was a bit arbitrary. That did seem to make sense, as far as foreign exchanging went, but apparently not for other reasons :-]
All I really remember was that she was supposedly from the far East. Probably from one of the cities less ravaged by Westernism. (I can imagine some strong nudity taboos are implicit within the culture)
I have to agree with your sentiment. Sure enough, if you go to places like Europe or Asia, there is a lot less stigma attached to nudity. (Not that it's a totally normal thing there either, but at least no one goes AAAAAAAHHH!!! NEKKID PEOPLE!!!)
I once heard a (true) story about a female Japanese foreign exchange student, staying with an American family. One night, they all decided to go for a dip in the family jacuzzi. When this young woman came to join them, she was not wearing anything.
Obviously, this caused a bit of confusion. It basically ended with the father-type figure sitting down with her, and explaining how nudity has very strong sexual overtones, and therefore that modesty was an important thing to uphold.
Her response was something along the lines of, "But bathing is not sexual."
(If anyone knows the original source of this story, please chime in. There is considerable bitrot in the recollection above).
In any case, it was quite eye-opening. The sad part of all this is, the way nudity keeps on being such a Big Deal in our society is by people making a big deal about it. I mean, if parents would just sit down with their (pre-puberty) kids, and pull out a Play{boy,girl} magazine, and just explain what is pornography, why it's so popular, how it can be good, how it can be bad, etc. etc.-- it will become a non-issue. Kids will see a porn site, say "bah!", and keep right on surfing to the Pokemon site they were looking for. There's no reason why an 8-year old can't be as mature about such things as a 21-year old.
(Warning, blatant plug to follow)
fsv - 3D File System Visualizer
This was released just last month. It's LGPL'ed, built on OpenGL/GTK+, and while it lacks many features of the original fsn (and isn't even at 1.0 yet) it sports a slicker interface, and not one but two distinct approaches to visualizing the file system.
There have been some noises to making this into a Nautilus optional view mode, which would be pretty cool (since the program would then have a real file manager backend, and what with XFree4.0/DRI coming around the bend...)
Definitely. I'm not sure at what -On it happens, but at -O9 (with -Wall) you get the "variable might be used before initialization" warnings which are very helpful. (There might be a -Wsomething flag for it, but I never looked into those)
Seeing some of the other comments posted here, however, it seems -Wall isn't quite all it's cracked up to be. I'll have to dig through the gcc docs a little. (Not to mention cajole the boys at Cygnus to add a -Whit-me-with-everything-youve-got flag or something
Some niceties cc gets that gcc doesn't:
There are others, but alas, I don't have a big hairy codebase under development right now to give more examples
To gcc's credit, it does do some pretty spiffy control-flow analysis with -O9 ("variable foo may be used before initialization", "statement is unreachable", etc.). But still, I don't consider a program done until I have an excuse for each and every warning given by SGI's compiler.
(Back to gcc, I'll have to try -W along with -Wall... that really turns up the analness? I'd use -ansi, except that it takes out nice things like inline functions and printf'ing long long ints)
Fast binaries rock!! GO SGI!!!
(*dances jig*)
I'm wondering, especially since they went the whole nine yards to release this under GPL-- will this be a new backend to gcc, or is it a whole new animal?
While I haven't had cause to complain about gcc's compiled-binary performance, I will go gaga if [SGI's compiler] has the same code-analysis capability as the IRIX cc. Having lint practically built right in is soooooo nice for debugging... if you can build it cleanly with -fullwarn, you can build it anywhere. (IMHO, gcc's greatest fault is that it's too damned lenient }:->
And now that you mention it, I've been wondering... will PS licensing present an issue for the up-and-coming free-software dps/dgs implementations?
Part of the GNUstep project has a Display Postscript reimplementation, which isn't that different. Someone here posted in the last OSX article that DPDF is better because it doesn't need as advanced a rendering system to work (as PDF lacks the Turing-completeness of PS).
What I'm wondering, however, is if DPDF/Quartz can be (efficiently) made network-transparent. At least with DPS this is possible, and the flexibility of the protocol lets you do some neat things in that vein....
Interesting idea, but it would probably just be more efficient to combine the editor with xdvi (the engine, not the interface!) rather than gv... that way, you get rid of the PS/PDF stage, which (in your example) is an intermediate between the editor and the screen anyway.