> Could somebody please enlighten me? I don't get the point at all.
I'll try to give it a go. I have several Debian boxes, and mostly use apt, but every now and then I need to install something for which there is no.deb, and stow is perfect for that. I have an m68k cross-compiler version of gcc (for Palm(tm) development), a locally modified version of the GTK canvas, and a few other obscure, specialized bits of software, all of which are "stow"-ed. I have realized many of the advantages described in the article -- I can uninstall these things cleanly, and move between versions just by unstowing the old one and stowing the new one.
I do think the article (and much of the commentary here) overstates the role of stow. It's not a substitute for a package manager, and the way it works makes it unsuitable for system-level software that, for instance, might need to set up cron jobs, require scripts in/etc/init.d, or be configured from a file in the/etc directory. But it *is* very useful for those occasional, obscure bits of software which primarily consist of libraries and include-headers, or non-system executables.
Stow itself is not new, and interestingly is packaged by debian -- I got it by "apt-get install stow"...
This might be just the sort of thing to fill a little niche in the consumer marketplace. I personally enjoy audio dramas, as well as a lot of spoken-word work, and it's hard to find in the commercial marketplace. Presumably this is because there is insufficient demand for it to catch the eye of big distributors. I, for one, would welcome this. Might even pay a buck or two for it.
We three pings, connectionless, Seek out hosts by IP address, By hub, by switch, Without a glitch, Sixty-five K or less.
Similar gizmo at NASM in DC
on
Robocoaster
·
· Score: 1
The National Air and Space Museum in DC has something similar, it's a flight simulator that basically consists of two seats and a flat-screen monitor inside a clamshell that can be rolled and pitched. In that case, the effect is greatly aided by the lack of visual cues other than those provided by the screen. The main problem is that they charge six bucks for three minutes on the thing.
Soviet Russia is a perfectly well-defined object -- The Russian Soviet Federated Socialist Republic was one of 15 Soviet Socialist Republics in the old USSR. It is just as correct as "Soviet Ukraine" or "Confederate Tennessee" or "Colonial Uttar Pradesh."
> You cannot drink fab quality water because it a large concentration gradient would form and minerals from the other fluids in your body would be depleted by the migration into the ultra pure water.
This has made my BS detector twitch. As soon as the pure water hits my mouth, it becomes impure because it mixes with my spit, so there's really no such thing as "drinking ultra-pure water." Water with the same concentration of saline as your body is actually much more dangerous than fresh water, and fresh water supplies all over the world have widely varying concentrations of minerals, yet people survive on them.
Maybe I'm missing something, but I invoke common sense to assert that as long as the mineral concentration of fresh water is reasonably low, the precise value is not important, and furthermore that the value of zero is not special.
Several of my friends have OSX laptops, and I don't dispute the props they're getting here, they're pretty and stable, lots of familiar tools, pleasant to develop on/for, all of that is true.
But what about openness, in the opposite-of-proprietary sense? What about community control of the kernel? This is a serious question -- I've never submitted a kernel patch to linux, never hacked my own kernel or written a device driver, but I *have* benefitted from those who've done it -- the scroll-knob on my sony vaio works on my OS because the Linux kernel is open, and some developer out there with a completely unrelated day job hacked up a driver for it. Openness means there's a community, and the community has variety in its goals and breadth in its interests. The hard-nosed economic benefit is that GNU/Linux works on commodity hardware, but the less tangible benefit is the vigor that comes from decentralization. It's the flip side of the chaos and infighting, and I think maybe sometimes we forget the difference between participating in a community, however deeply or shallowly we do that, and buying a product.
OS X is pretty, but it's also proprietary, and restricted in its hardware. I'm not saying its evil or anything, I just couldn't help wondering how many of the commentors really have their eyes open.
Maybe for PC peripherals, but one of the noteworthy features of their XBOX hardware venture is just how infrequently and insignificantly the name "Microsoft" appears on the box and in the ads. Compare, for instance, the number of occurrences of the word "Sony" on a PS2. It seems clear that it's "XBOX" that they're trying to brand.
I've only used nVidia hardware lately, they have good free-as-in-beer drivers that seem to work OK. I gave the ATI site a once-over, but didn't see any obvious link for Linux/XF86 reference drivers -- is ATI good about stuff like that?
It would be within the Linux/open-source idiom, in any case, out "out-authentic" the trade-mark holders by going to "Davejira" and "Mojira", respectively.
Seems to me they're trying to square the "everything first" circle -- nobody will buy a digital TV until there are digital broadcasts, and nobody will broadcast digitally until there are receivers, and the market deadlocks itself. (See also hydrogen as an automotive fuel, etc. etc.)
In all of your examples, the new technology was backward-compatible -- it's possible to receive a color-TV signal on a black-and-white receiver, or a stereo radio program on a monaural receiver, and so forth. The FCC believes this is not the case with digital TV.
The FCC could still be wrong, of course -- there's a DVD infrastructure, it seems possible (to me) that the much-beloved market could find a way to induce DVD-watchers to buy sets that can receive digital broadcast signals, and build a user base for the broadcasters that way.
The ever-resourceful Bruce Perens wrote a cool gizmo called "electric fence", which I have used on many occasions. It doesn't actually do bounds checking as such, what it does is provide a replacement "malloc" that allocates unwritable pages either above or below every memory allocation. Your application will then segfault when it misbehaves, and you can then use conventional debugging tools to track down the
It's very "non-invasive" -- all you have to do to use it is link against it, and maybe set a few environment variables.
I haven't done it, but you certainly can. Back in the day, the PCChips folks used to publish updated BIOS object code in a form such that it could be flashed into the chip, generally by booting off a suitably-rigged floppy. Doubtless many manufacturers do this. Presumably this thing can be disassembled, hacked, and then flashed and/or burned into an EEPROM.
I've lost the links, but I looked into something similar for a BIOS that I thought might have a Y2K problem. Downloaded the update, decided to "wait and see", and after Y2K, it was fine, so I never bothered to load it.
Not a great analogy -- new ideas are like new land, not like walking on somebody else's land. IP grants big companies all the coastlines, and allows them to forbid new land from connecting to old land....
Also, historically, real estate was a much greater obstacle to mobility than today. In eighteenth-century London, many of the roads were privately owned, and there were toll tages all over the place. Public ownership of city streets, and easements for roads on rural land, are relatively recent inventions.
Because sendmail sucks but is open, there are lots of alternative mail transport agents out there for Unix systems -- bad open software doesn't have to be fixed if it can be bypassed. Bad closed software is just, well, bad.
In the first place, even though KDE does have an integrated browers, it's not integrated into the operating system -- it can't be, because KDE isn't an operating system, it's a desktop environment. And in the second place, while it is admittedly rather large, the KDE desktop API is open, so a competitor can write a KDE file/web/whatever browser that takes full advantage of the integration also.
There's a proof-of-concept technology for wireless transmission of image data that dates back quite a ways, actually. And yes, there are battery-powered TVs.
So can you describe or link to this refutation? It sounds exactly like the more sophisticated version of Searle's argument I'm looking for.
-- A.
Re:Chinese Rooms and Software Guys
on
Arguing A.I.
·
· Score: 2, Interesting
I, for one, have yet to hear a compelling version of the Chinese Room argument. The version I have heard has a non-Chinese speaking human in a room, with a list of rules (in a language the human understands) for processing Chinese characters, which he uses to generate additional Chinese characters. The human dutifully does this, and in the process, ends up reading a story in Chinese and then answering questions (also in Chinese) about it, all unknowingly. Searle (or his caricatures, anyways) then point triumphantly to the man, proclaim "but he doesn't know Chinese!!!", and then sit back smugly as though they had refuted something important.
It is totally obvious to me, anyways, that the man is not required to know Chinese any more than my Pentium III is required to know LISP -- the man is the one component of a system which, as a whole, evidently does understand Chinese.
As for the mind/brain connection, this seems to be the same misunderstanding -- the mind is software, and one of the open questions is the degree to which this software is platform-dependent. Searle (again, perhaps only Searle's caricatures) seems to think, more or less axiomatically, that the mind can only run on the meat-machine, but seems to offer no evidence.
I welcome more sophisticated versions of Searle's arguments, if you've got 'em.
Because of it's openness, Linux is also self-repairing. Clutter in main directories is a real problem, and instead of ranting about it, at least one person went ahead and built a work-around, by writing "stow".
This is a utility that allows you to put executables for packages where you like, and then automatically creates symlinks from the main/usr/bin,/usr/lib, etc. directories into the right place. It destroys those links when you unstow, and minimizes link-count by putting the links in at as high a level as possible, and unlike package-maintenance schemes, doesn't rely on a package database, so there's no danger of it being incomplete or out of date.
Well, except there are other countermeasures besides blowing up the transmitters. For one thing, an attacker can just add air-drop several new transmitters throughout the countryside -- jams the civillian radio, plus changes the RF background so it's not the one the army calibrated for, and their detection is useless.
On the civilian side, I bet there are fewer power plants than there are RF transmitters. If you insist on blowing stuff up, blow up those.
I am employed at a US national lab, involved in a scientific programming project for which we make the source code publicly available. We have an apparent difficulty with incorporating GPL'd code into this project. The problem is that code (or scientific papers, etc.) produced by the US government is, by statute, not subject to copyright. Government-produced code is just plain open. This means that the copyright hook the GPL uses to require subsequent copiers to disclose their source code does not apply. We cannot use licensing features to "bind our successors", as they say, in the way that the GPL would like us to.
What are the implications of this for incorporating GPL'd code into our project? Can we do it at all?
Slashdot Mirror
> Could somebody please enlighten me? I don't get the point at all.
.deb, and stow is perfect for that. I have an m68k cross-compiler version of gcc (for Palm(tm) development), a locally modified version of the GTK canvas, and a few other obscure, specialized bits of software, all of which are "stow"-ed. I have realized many of the advantages described in the article -- I can uninstall these things cleanly, and move between versions just by unstowing the old one and stowing the new one.
/etc/init.d, or be configured from a file in the /etc directory. But it *is* very useful for those occasional, obscure bits of software which primarily consist of libraries and include-headers, or non-system executables.
I'll try to give it a go. I have several Debian boxes, and mostly use apt, but every now and then I need to install something for which there is no
I do think the article (and much of the commentary here) overstates the role of stow. It's not a substitute for a package manager, and the way it works makes it unsuitable for system-level software that, for instance, might need to set up cron jobs, require scripts in
Stow itself is not new, and interestingly is packaged by debian -- I got it by "apt-get install stow"...
This might be just the sort of thing to fill a little niche in the consumer marketplace. I personally enjoy audio dramas, as well as a lot of spoken-word work, and it's hard to find in the commercial marketplace. Presumably this is because there is insufficient demand for it to catch the eye of big distributors. I, for one, would welcome this. Might even pay a buck or two for it.
We three pings, connectionless,
Seek out hosts by IP address,
By hub, by switch,
Without a glitch,
Sixty-five K or less.
The National Air and Space Museum in DC has something similar, it's a flight simulator that basically consists of two seats and a flat-screen monitor inside a clamshell that can be rolled and pitched. In that case, the effect is greatly aided by the lack of visual cues other than those provided by the screen. The main problem is that they charge six bucks for three minutes on the thing.
Soviet Russia is a perfectly well-defined object -- The Russian Soviet Federated Socialist Republic was one of 15 Soviet Socialist Republics in the old USSR. It is just as correct as "Soviet Ukraine" or "Confederate Tennessee" or "Colonial Uttar Pradesh."
> You cannot drink fab quality water because it a large concentration gradient would form and minerals from the other fluids in your body would be depleted by the migration into the ultra pure water.
This has made my BS detector twitch. As soon as the pure water hits my mouth, it becomes impure because it mixes with my spit, so there's really no such thing as "drinking ultra-pure water." Water with the same concentration of saline as your body is actually much more dangerous than fresh water, and fresh water supplies all over the world have widely varying concentrations of minerals, yet people survive on them.
Maybe I'm missing something, but I invoke common sense to assert that as long as the mineral concentration of fresh water is reasonably low, the precise value is not important, and furthermore that the value of zero is not special.
Several of my friends have OSX laptops, and I don't dispute the props they're getting here, they're pretty and stable, lots of familiar tools, pleasant to develop on/for, all of that is true.
But what about openness, in the opposite-of-proprietary sense? What about community control of the kernel? This is a serious question -- I've never submitted a kernel patch to linux, never hacked my own kernel or written a device driver, but I *have* benefitted from those who've done it -- the scroll-knob on my sony vaio works on my OS because the Linux kernel is open, and some developer out there with a completely unrelated day job hacked up a driver for it. Openness means there's a community, and the community has variety in its goals and breadth in its interests. The hard-nosed economic benefit is that GNU/Linux works on commodity hardware, but the less tangible benefit is the vigor that comes from decentralization. It's the flip side of the chaos and infighting, and I think maybe sometimes we forget the difference between participating in a community, however deeply or shallowly we do that, and buying a product.
OS X is pretty, but it's also proprietary, and restricted in its hardware. I'm not saying its evil or anything, I just couldn't help wondering how many of the commentors really have their eyes open.
Maybe for PC peripherals, but one of the noteworthy features of their XBOX hardware venture is just how infrequently and insignificantly the name "Microsoft" appears on the box and in the ads. Compare, for instance, the number of occurrences of the word "Sony" on a PS2. It seems clear that it's "XBOX" that they're trying to brand.
I've only used nVidia hardware lately, they have good free-as-in-beer drivers that seem to work OK. I gave the ATI site a once-over, but didn't see any obvious link for Linux/XF86 reference drivers -- is ATI good about stuff like that?
Assuming you weren't trolling:
Mach 7.6 is a speed, not an acceleration. A hypersonic passenger vehicle will presumably travel with moderate acceleration until reaching high speed.
At 1/2-earth-gravity acceleration, you get one sea-level Mach number per minute, more or less, so you'll be at Mach 7.6 a few minutes after launch.
Mod parent up!
It would be within the Linux/open-source idiom, in any case, out "out-authentic" the trade-mark holders by going to "Davejira" and "Mojira", respectively.
Seems to me they're trying to square the "everything first" circle -- nobody will buy a digital TV until there are digital broadcasts, and nobody will broadcast digitally until there are receivers, and the market deadlocks itself. (See also hydrogen as an automotive fuel, etc. etc.)
In all of your examples, the new technology was backward-compatible -- it's possible to receive a color-TV signal on a black-and-white receiver, or a stereo radio program on a monaural receiver, and so forth. The FCC believes this is not the case with digital TV.
The FCC could still be wrong, of course -- there's a DVD infrastructure, it seems possible (to me) that the much-beloved market could find a way to induce DVD-watchers to buy sets that can receive digital broadcast signals, and build a user base for the broadcasters that way.
The ever-resourceful Bruce Perens wrote a cool gizmo called "electric fence", which I have used on many occasions. It doesn't actually do bounds checking as such, what it does is provide a replacement "malloc" that allocates unwritable pages either above or below every memory allocation. Your application will then segfault when it misbehaves, and you can then use conventional debugging tools to track down the
It's very "non-invasive" -- all you have to do to use it is link against it, and maybe set a few environment variables.
I haven't done it, but you certainly can. Back in the day, the PCChips folks used to publish updated BIOS object code in a form such that it could be flashed into the chip, generally by booting off a suitably-rigged floppy. Doubtless many manufacturers do this. Presumably this thing can be disassembled, hacked, and then flashed and/or burned into an EEPROM.
I've lost the links, but I looked into something similar for a BIOS that I thought might have a Y2K problem. Downloaded the update, decided to "wait and see", and after Y2K, it was fine, so I never bothered to load it.
Not a great analogy -- new ideas are like new land, not like walking on somebody else's land. IP grants big companies all the coastlines, and allows them to forbid new land from connecting to old land....
Also, historically, real estate was a much greater obstacle to mobility than today. In eighteenth-century London, many of the roads were privately owned, and there were toll tages all over the place. Public ownership of city streets, and easements for roads on rural land, are relatively recent inventions.
Because sendmail sucks but is open, there are lots of alternative mail transport agents out there for Unix systems -- bad open software doesn't have to be fixed if it can be bypassed. Bad closed software is just, well, bad.
Oh, go ahead, be polemic.
In the first place, even though KDE does have an integrated browers, it's not integrated into the operating system -- it can't be, because KDE isn't an operating system, it's a desktop environment. And in the second place, while it is admittedly rather large, the KDE desktop API is open, so a competitor can write a KDE file/web/whatever browser that takes full advantage of the integration also.
There's a proof-of-concept technology for wireless transmission of image data that dates back quite a ways, actually. And yes, there are battery-powered TVs.
So can you describe or link to this refutation? It sounds exactly like the more sophisticated version of Searle's argument I'm looking for.
-- A.
I, for one, have yet to hear a compelling version of the Chinese Room argument. The version I have heard has a non-Chinese speaking human in a room, with a list of rules (in a language the human understands) for processing Chinese characters, which he uses to generate additional Chinese characters. The human dutifully does this, and in the process, ends up reading a story in Chinese and then answering questions (also in Chinese) about it, all unknowingly. Searle (or his caricatures, anyways) then point triumphantly to the man, proclaim "but he doesn't know Chinese!!!", and then sit back smugly as though they had refuted something important.
It is totally obvious to me, anyways, that the man is not required to know Chinese any more than my Pentium III is required to know LISP -- the man is the one component of a system which, as a whole, evidently does understand Chinese.
As for the mind/brain connection, this seems to be the same misunderstanding -- the mind is software, and one of the open questions is the degree to which this software is platform-dependent. Searle (again, perhaps only Searle's caricatures) seems to think, more or less axiomatically, that the mind can only run on the meat-machine, but seems to offer no evidence.
I welcome more sophisticated versions of Searle's arguments, if you've got 'em.
-- A.
Because of it's openness, Linux is also self-repairing. Clutter in main directories is a real problem, and instead of ranting about it, at least one person went ahead and built a work-around, by writing "stow".
/usr/bin, /usr/lib, etc. directories into the right place. It destroys those links when you unstow, and minimizes link-count by putting the links in at as high a level as possible, and unlike package-maintenance schemes, doesn't rely on a package database, so there's no danger of it being incomplete or out of date.
This is a utility that allows you to put executables for packages where you like, and then automatically creates symlinks from the main
Well, except there are other countermeasures besides blowing up the transmitters. For one thing, an attacker can just add air-drop several new transmitters throughout the countryside -- jams the civillian radio, plus changes the RF background so it's not the one the army calibrated for, and their detection is useless.
On the civilian side, I bet there are fewer power plants than there are RF transmitters. If you insist on blowing stuff up, blow up those.
I am employed at a US national lab, involved in a scientific programming project for which we make the source code publicly available. We have an apparent difficulty with incorporating GPL'd code into this project. The problem is that code (or scientific papers, etc.) produced by the US government is, by statute, not subject to copyright. Government-produced code is just plain open. This means that the copyright hook the GPL uses to require subsequent copiers to disclose their source code does not apply. We cannot use licensing features to "bind our successors", as they say, in the way that the GPL would like us to. What are the implications of this for incorporating GPL'd code into our project? Can we do it at all?