Obviously, or else there wouldn't be an article talking about it.
Anybody who seriously wants to compromise the Linux kernel isn't going to give up after one failed attempt. That one probably wasn't even the first or the last attempt - any serious attacker makes a series of probes to identify the extent of a system's defenses before trying in earnest. Now that the route through BitKeeper has been explored, some other avenue will be attempted. etc...
And the issue of trusted toolchains is still interesting, one might go after a less vigorously-tested component like ar, ld, cpp, or libbfd. Any build tool could be used to insert a backdoor, not just gcc itself.
Of course, it would certainly be simpler if one could just offer a submission through the front door and fool enough people to get it accepted. The likelihood is certainly low, but if it got past the front door, the likelihood of it ever being detected is lower still.
If you're getting interference from microwave ovens then it's time to call the FCC and have it stopped. A leaky microwave oven is a serious health hazard.
I've got a scanner that receives up in the 2.4GHz range, and I've swept thru it a couple of times looking for signal while my microwave was operating - not a peep, even at 3 inches away.
I don't know anything about Danger Mouse, but in the US once a song has been published, anyone else can license the song for subsequent recording. This is compulsory, it's automatic and nobody can interfere with it. All you have to do is pay the royalties for the song.
http://www.harryfox.com/mechanical.html
For performance rights, you go thru either ASCAP or BMI.
Yeah, I had economics back in... junior high, come to think of it.
48 year old mothers who buy whatever their trendy children want and spoil them rotten are stupid. If they're willing to waste their money like that, cool, *that* is certainly allowed in a free market.
Re: monopolies on Britney - actually, I have no problem with this. Sony invents the minidisc, they're the sole source of the technology. The price is whatever they say it is. As the inventor/creator of the product, it is their prerogative, for some amount of time. That's the purpose of intellectual property laws - to grant a limited-duration monopoly to inventors/creators so that they can be rewarded for their creative efforts. I think the duration of patents/copyrights is way overblown, but that's a separate topic. Sony can choose to license their technology out to other vendors, but nobody can force them to do so. Until they do license it out, it is unique.
Britney's "product" is unique - the total package of her looks, her voice, and her sound. The fact that there is only one single suppluer of her product is perfectly acceptable. She can license out her songs to other performers, just like Sony can license their patented technology to other manufacturers. Or they can choose to keep it to themselves. It's their creation, they have the right to determine how to exploit it.
There's a philosophical question here, since art/music is purely subjective to begin with - just what is someone's creative output *worth* to you? I like classical/baroque music, I think Bach is a zillion times better than anything out there. I guess it's worth more to me. But I'm not going to pay 1000x the cost of a Britney Spears album for a Bach recording. What is the music worth, as a commodity?
I think supply-and-demand is working reasonably well here. There's only one supplier of Britney's music, but there are multiple suppliers of "music by young blond female singers". You can choose to buy someone else's product, just like I could buy Sharp or Panasonic instead of Sony. The point is you have to actually go to an alternate supplier. When all of your music comes from RIAA members, then you haven't actually chosen an alternate supplier, and so you're stuck with their prices.
1) you have no idea how much trouble it is to get to the taillights (or any of the signal lights, for that matter) of a Ford Probe. Trust me, it takes longer than five minutes. Worse is the reassembly time, things never go back together the way they were originally seated...
2) five years is too optimistic. Look around you on the road and see how many new/late-model cars are driving around with missing/burnt-out signal lights. It seems to me that either OEM signal bulb quality has really gone downhill, or the bulbs are being driven out of spec. Having 3 out of 4 front signal bulbs burn out within a few weeks of each other on my car after only 4 years tells me there's something systematically wrong here.
3) since signal lamps are safety devices, it's better that they *never* fail.
4) $100 is exorbitant yes, but I'm a bleeding edge tech-freak and a car fanatic so I'm willing to spend it. If you're not, that's OK, don't. In a few years all of the car manufacturers will have completely migrated to LEDs, LED production volumes will go up, and unit prices will go down. There are already a couple concept cars out there using white Luxeon arrays for headlights. (I think that's a dumb idea personally; HID is still the efficiency winner here.) Solid state lighting is going to completely replace small-incandescent in a very short time. In the time since I completed this project, the end of last year, the price of the Luxeons that I used has dropped 33%, from $15 to $10 each. That's a sizable drop in only 4 months. The price drops will only continue to accelerate.
"isn't it hard" - well, it's not as simple as dropping in a so-called "LED-replacement" bulb. The fact is, those bulbs are crap and don't provide anywhere near the amount of light that's needed.
In my setup using 4 Luxeon stars for one turn signal, the stars draw enough current to produce a regular blinking pattern. When you're actually using enough LEDs to provide the equivalent amount of light as the incandescent bulb you're replacing, the amount of current drawn will probably be enough to trigger the blinker circuit, even if it's not as much as before. My Luxeons draw 550mA through the blinkers. Not as much as the 2.5A that the incandescents used, but enough. Of course, if I convert the taillights too, then the entire combo will not draw enough current by themselves, and I'll have to use a loading resistor in parallel to make up the difference.
So it's not a straight drop-in, but it's not that tough to make it work, either.
Btw, my car uses an electronic blinker control, but it still expects a minimum level of current. Just because you have an electronic control doesn't mean it will be immune to these changes; they're supposed to monitor the current level so they can detect burnt-out bulbs.
Re:Other uses than indicators
on
The Blues for LEDs
·
· Score: 5, Interesting
Red LEDs are definitely great for brake lights. I've gotten really fond of amber LEDs for turn signals, even though they're still ridiculously expensive compared to incandescent bulbs. I converted my car's turn signals to LEDs here.
I'll probably convert the tail lights pretty soon. Having to replace any signal bulb once is one time too many, I think.
Both of my firewire drive cases have blue LEDs, and there's two years betwen when I purchased them. I didn't notice how bright they were right away, but when the room lights are off there are two piercing beams of light shining out. This is definitely a bit distracting since they're sitting on the same rack as my A/V gear, and they're very visible when I'm watching movies etc. But they make a pretty intense nightlight...
But on a related note, I have some pro-audio wireless mic gear that uses 800MHz; I think it's fairly common in UHF pro gear. I'd really hate to have to replace this stuff because I can't get a clean signal for my band gigs, and I'm sure I'm far from alone here. (And that leads me to a digression - I wish more of this pro gear would use programmable oscillators/ frequency synthesizers so they wouldn't lock you into just one or two frequencies. Bleah...)
Interesting point. Let's see, how might this work in reality?
Assume you bought a binary Linux distro from god-knows-where, and the gcc that it shipped with has a trojan. The trojan must be pretty small/obscure, to have made it into the distro in the first place. How many opportunities will you have to detect it?
If it works by inserting source code into its own compilation stream, then even bootstrapping a new version of gcc on top of it probably wouldn't eliminate it or make it visible. Of course, a complex trojan would probably be pretty sensitive to the version of libgcc/crt in order to insert itself in a useful location, so maybe an incompatible change there would trip it up. Hard to tell.
I get the feeling, with the GNU CVS repository being attacked etc., that people have tried to insert trojans already through the normal code submission process, been frustrated/blocked, and so resorted to that alternate route.
There's a hole in this argument - the "good guys" have to detect the hole before the "bad guys." Despite the huge number of eyes reviewing the code, there is no guarantee that the open source community will find out about a bug in time to prevent your system from being exploited.
The day a US DOD Linux system gets hacked, no amount of "we can patch it faster than closed source" is going to appease the angry mob, and the closed-source vendors are going to have a field day, regardless of their own track record.
For the DOD, the fact that thousands of people around the world have reviewed the source is irrelevant; due diligence will require them to review it themselves, and so the cost of ownership will be much the same as for a proprietary source product.
The Sony DSC-T1 still camera records 640x480 30fps video, limited only by the memory card capacity.
I find it ironic that their newest camcorders, which can also record MPEG to MemoryStick, only record MPEG1 at 320x200. It's pretty ugly stuff. Mebbe I should've bought the still camera instead of the camcorder...
I can't put any trust in anonymously posted news. So, you either put your name on it, and risk future censorship, or leave it unsigned, and risk being totally ignored. I think this is only going to be of any value if postings are signed.
When are people going to realize that TCP-connection based information serving doesn't scale? HTTP, BitTorrent, neither of them stand a chance against a huge number of clients.
This is a job for IP Multicast. Set up "broadcasters" (actually multicasters, obviously) pushing out the data on a fixed schedule, the way video-on-demand (yet another misnomer) works. Use trackers to allow clients to find a multicast group carrying the feed they want at a speed close to their line speed, with a start-time within a particular window around "now". Presto, each information provider only needs to transmit a small number of copies of the data, instead of one copy per requesting client. Overall Internet bandwidth requirements decrease, while everybody gets the data they're looking for at best possible speed.
Sadly, my experience echoes yours. And seeing how the software I spend most of my time working on has only a lowly command line interface, I guess it'll be some time before we see any CIOs enthusiastically dumping it on their beleaguered IT staff. It's tough to be an engineer emphasizing function over form in such a superficial world.
(Me, I read the issues lists and defer screen shots. Eventually I get to analyzing whether the menus and layouts make sense to me, but that comes long after "does it do what I need, at all?")
You don't have to shoot down a GPS satellite to confuse a GPS receiver. All you need are a couple well-synchronized transmitters with some forged signals. The algorithm used by xntpd/tickadj is sufficient for *introducing* imperceptible drift into the timecode.
Of course, you might have a problem deploying your transmitters near enough to a Navy vessel to be effective, unless you happen to have your own LEO satellites, carrying otherwise legitimate earthbound communication/TV/etc....
I wanted to model the characteristics of a turbocharger I was planning to install in my car. It seemed to me a spreadsheet was the ideal way to try various scenarios. Of course, modeling a turbo requires entering lots of lists of numbers. I had to fight with it, but despite my years of programming experience, figuring out Excel was easier and faster than writing my own custom app for the job.
Now I can just enter engine size, compression ratios, etc., select from a variety of compressor maps, and presto - power curves computed without breaking a sweat.
Of course, I wrote about doing this in my presentation to the Sun User Group in 1991 "GNU & You, Building a Better World" which I developed while working at JPL. And yes, I wrote the jobserver code that allows gmake to spawn parallel jobs without swamping the machine, the way the old loadaverage-based code did.
The motivation for my work in 1991 was not much different than this, although back then my problem was building the X11 distro, and all of the imake crap that was in there. Since the paper itself is no longer online, a brief summary:
imake sucks. In the X11R4 distro, imake-generated Makefiles accounted for 11% of the disk space consumed by the source tree.
using extra CPUs for compilation is goodness.
Anybody with half a brain can write a better Makefile than imake produces, they just have to be bothered to do it.
Don't use for-loops to spawn recursive make's in subdirectories when there are no serial dependencies betwen those directories. This creates serialization points that bottleneck a parallel make needlessly.
On the flip side, don't write dependencies in a flat list when one element of the list depends on an earlier item in the list. When a parallel Make comes along and spawns them all of simultaneously, things will break.
In other words, always write your Makefiles such that the written dependencies reflect reality. Don't write
a: b c d
if 'd' depends on 'b' or 'c'.
Nice to see that people are finally catching on, after only 13 years.
I don't think I have any time at the moment to help out. But for the moment, I'm happy to think about what such a game might do.
re: game balance, and worlds where powerful magic items are plentiful/mundane vs worlds where they are scarce - perhaps we should take another step back. Treat GMing/world design as another player type, with bonuses and advancement for passing certain milestones. Have the game system allocate limited resources to each world, e.g. "you can define as many cool artifacts as you like, as long as the code fits in 64K." As the world progresses thru X number of players per Y period of time, the GM advances to a new level, earning more resources to use in developing the world.
This kinda says that items are unique, and once removed from your world they never reappear, which could be a drag. But figuring out when to recycle things will be a challenge... If some powerful party comes thru and slaughters everything in your dungeon, taking away all the treasure, you're kind of SOL.
But somewhere in here may be a workable idea, where the GM/world evolves and advances along with the players. It would be a bit like GodWars or somesuch.
One of the principle benefits of The Internet has been the previously-unknown ability to easily connect to people independent of their geographical location.
So now this "invention" tries to create "geography dependent" networking. Duh, we call that a "LAN". The idea is as old as networking itself; LANs have existed and been used for meaningful work long before The Internet came around. This is just the same old LAN slightly warmed over.
Now personally, if I were wandering down the street, I would probably rather *speak* to the people I run into and wanted to interact with. It's a helluva lot faster than typing, and nothing beats face-to-face interaction for high bandwidth low-latency communication.
Again, the point of The Internet was to bring people together who otherwise had no other means to interact. When you're in the same room with a bunch of other people, you have many far superior channels at your disposal.
As for the wandering store-and-forward mail-server/filedrop/whatever. This is like copying a file to a floppy disk and walking down the hall to the next computer, we called this "sneakernet" - again, not a new idea. The implementation may be a little slicker now, being wireless and so not requiring physical access. But in actual utility, you haven't gained much.
Everyone knows the maximum range specs for 802.11 are under perfect conditions with no sunspot activity, etc., and in The Real World your range is far more limited. You don't get to surreptitiously walk through a crowd and disseminate tons of information undetectably - there's a non-trivial connect-time, and anything that takes longer than a few seconds to transfer is going to be obvious. People are going to need to walk the same direction as you in a crowd. They're going to have to stay close to you to avoid signal fade from intervening objects or people, and/or they're going to have to have their own diversity antennas. Everyone will stick out plainly, and anyone who cares to monitor/surveil these people will have an easy job of it.
I really really love neat new gadgets and cool uses of technology, but this is not neat, new, cool, or useful.
There's probably not much point in responding to ACs but you're an idiot. GEM was already a mature windowing environment by 1989.
I have on my desk (even now) an Atari TT built in 1989 that ran rings around any MS/Intel box of the same vintage. 32 MHz 68030 with a 64-bit memory bus and speed to burn. What year did PCs start using 64-bit memory buses?
The simple fact that your feeble mind is only capable of comparing things in terms of Microsoft products completely proves my point.
I'm not sure what to think of that. PCs have always been cheap, compared to the alternatives (Sun/DEC/Apollo workstations). Unix on PCs was already a reality (BSDi, NetBSD) long before Linux existed. The fact that a free BSD distro never took over the hacking world the way Linux has tells me there's another factor...
Slashdot Mirror
Um, and that was detected....
Obviously, or else there wouldn't be an article talking about it.
Anybody who seriously wants to compromise the Linux kernel isn't going to give up after one failed attempt. That one probably wasn't even the first or the last attempt - any serious attacker makes a series of probes to identify the extent of a system's defenses before trying in earnest. Now that the route through BitKeeper has been explored, some other avenue will be attempted. etc...
And the issue of trusted toolchains is still interesting, one might go after a less vigorously-tested component like ar, ld, cpp, or libbfd. Any build tool could be used to insert a backdoor, not just gcc itself.
Of course, it would certainly be simpler if one could just offer a submission through the front door and fool enough people to get it accepted. The likelihood is certainly low, but if it got past the front door, the likelihood of it ever being detected is lower still.
If you're getting interference from microwave ovens then it's time to call the FCC and have it stopped. A leaky microwave oven is a serious health hazard.
I've got a scanner that receives up in the 2.4GHz range, and I've swept thru it a couple of times looking for signal while my microwave was operating - not a peep, even at 3 inches away.
I don't know anything about Danger Mouse, but in the US once a song has been published, anyone else can license the song for subsequent recording. This is compulsory, it's automatic and nobody can interfere with it. All you have to do is pay the royalties for the song.
http://www.harryfox.com/mechanical.html
For performance rights, you go thru either ASCAP or BMI.
Yeah, I had economics back in ... junior high, come to think of it.
48 year old mothers who buy whatever their trendy children want and spoil them rotten are stupid. If they're willing to waste their money like that, cool, *that* is certainly allowed in a free market.
Re: monopolies on Britney - actually, I have no problem with this. Sony invents the minidisc, they're the sole source of the technology. The price is whatever they say it is. As the inventor/creator of the product, it is their prerogative, for some amount of time. That's the purpose of intellectual property laws - to grant a limited-duration monopoly to inventors/creators so that they can be rewarded for their creative efforts. I think the duration of patents/copyrights is way overblown, but that's a separate topic. Sony can choose to license their technology out to other vendors, but nobody can force them to do so. Until they do license it out, it is unique.
Britney's "product" is unique - the total package of her looks, her voice, and her sound. The fact that there is only one single suppluer of her product is perfectly acceptable. She can license out her songs to other performers, just like Sony can license their patented technology to other manufacturers. Or they can choose to keep it to themselves. It's their creation, they have the right to determine how to exploit it.
There's a philosophical question here, since art/music is purely subjective to begin with - just what is someone's creative output *worth* to you? I like classical/baroque music, I think Bach is a zillion times better than anything out there. I guess it's worth more to me. But I'm not going to pay 1000x the cost of a Britney Spears album for a Bach recording. What is the music worth, as a commodity?
I think supply-and-demand is working reasonably well here. There's only one supplier of Britney's music, but there are multiple suppliers of "music by young blond female singers". You can choose to buy someone else's product, just like I could buy Sharp or Panasonic instead of Sony. The point is you have to actually go to an alternate supplier. When all of your music comes from RIAA members, then you haven't actually chosen an alternate supplier, and so you're stuck with their prices.
1) you have no idea how much trouble it is to get to the taillights (or any of the signal lights, for that matter) of a Ford Probe. Trust me, it takes longer than five minutes. Worse is the reassembly time, things never go back together the way they were originally seated...
2) five years is too optimistic. Look around you on the road and see how many new/late-model cars are driving around with missing/burnt-out signal lights. It seems to me that either OEM signal bulb quality has really gone downhill, or the bulbs are being driven out of spec. Having 3 out of 4 front signal bulbs burn out within a few weeks of each other on my car after only 4 years tells me there's something systematically wrong here.
3) since signal lamps are safety devices, it's better that they *never* fail.
4) $100 is exorbitant yes, but I'm a bleeding edge tech-freak and a car fanatic so I'm willing to spend it. If you're not, that's OK, don't. In a few years all of the car manufacturers will have completely migrated to LEDs, LED production volumes will go up, and unit prices will go down. There are already a couple concept cars out there using white Luxeon arrays for headlights. (I think that's a dumb idea personally; HID is still the efficiency winner here.) Solid state lighting is going to completely replace small-incandescent in a very short time. In the time since I completed this project, the end of last year, the price of the Luxeons that I used has dropped 33%, from $15 to $10 each. That's a sizable drop in only 4 months. The price drops will only continue to accelerate.
"isn't it hard" - well, it's not as simple as dropping in a so-called "LED-replacement" bulb. The fact is, those bulbs are crap and don't provide anywhere near the amount of light that's needed.
In my setup using 4 Luxeon stars for one turn signal, the stars draw enough current to produce a regular blinking pattern. When you're actually using enough LEDs to provide the equivalent amount of light as the incandescent bulb you're replacing, the amount of current drawn will probably be enough to trigger the blinker circuit, even if it's not as much as before. My Luxeons draw 550mA through the blinkers. Not as much as the 2.5A that the incandescents used, but enough. Of course, if I convert the taillights too, then the entire combo will not draw enough current by themselves, and I'll have to use a loading resistor in parallel to make up the difference.
So it's not a straight drop-in, but it's not that tough to make it work, either.
Btw, my car uses an electronic blinker control, but it still expects a minimum level of current. Just because you have an electronic control doesn't mean it will be immune to these changes; they're supposed to monitor the current level so they can detect burnt-out bulbs.
Red LEDs are definitely great for brake lights. I've gotten really fond of amber LEDs for turn signals, even though they're still ridiculously expensive compared to incandescent bulbs. I converted my car's turn signals to LEDs here.
I'll probably convert the tail lights pretty soon. Having to replace any signal bulb once is one time too many, I think.
Both of my firewire drive cases have blue LEDs, and there's two years betwen when I purchased them. I didn't notice how bright they were right away, but when the room lights are off there are two piercing beams of light shining out. This is definitely a bit distracting since they're sitting on the same rack as my A/V gear, and they're very visible when I'm watching movies etc. But they make a pretty intense nightlight...
Excuse me, I have authored a couple items that are in the Linux kernel. I understand very well how it works.
And you might just peek at this article for a refresher on how someone might "just drop code into the kernel..."
900 MHZ, as someone already posted.
But on a related note, I have some pro-audio wireless mic gear that uses 800MHz; I think it's fairly common in UHF pro gear. I'd really hate to have to replace this stuff because I can't get a clean signal for my band gigs, and I'm sure I'm far from alone here. (And that leads me to a digression - I wish more of this pro gear would use programmable oscillators/ frequency synthesizers so they wouldn't lock you into just one or two frequencies. Bleah...)
Interesting point. Let's see, how might this work in reality?
Assume you bought a binary Linux distro from god-knows-where, and the gcc that it shipped with has a trojan. The trojan must be pretty small/obscure, to have made it into the distro in the first place. How many opportunities will you have to detect it?
If it works by inserting source code into its own compilation stream, then even bootstrapping a new version of gcc on top of it probably wouldn't eliminate it or make it visible. Of course, a complex trojan would probably be pretty sensitive to the version of libgcc/crt in order to insert itself in a useful location, so maybe an incompatible change there would trip it up. Hard to tell.
I get the feeling, with the GNU CVS repository being attacked etc., that people have tried to insert trojans already through the normal code submission process, been frustrated/blocked, and so resorted to that alternate route.
Still, hard to tell...
There's a hole in this argument - the "good guys" have to detect the hole before the "bad guys." Despite the huge number of eyes reviewing the code, there is no guarantee that the open source community will find out about a bug in time to prevent your system from being exploited.
The day a US DOD Linux system gets hacked, no amount of "we can patch it faster than closed source" is going to appease the angry mob, and the closed-source vendors are going to have a field day, regardless of their own track record.
For the DOD, the fact that thousands of people around the world have reviewed the source is irrelevant; due diligence will require them to review it themselves, and so the cost of ownership will be much the same as for a proprietary source product.
The Sony DSC-T1 still camera records 640x480 30fps video, limited only by the memory card capacity.
I find it ironic that their newest camcorders, which can also record MPEG to MemoryStick, only record MPEG1 at 320x200. It's pretty ugly stuff. Mebbe I should've bought the still camera instead of the camcorder...
So maybe P2P gossip isn't such a bad thing... ;)
I can't put any trust in anonymously posted news. So, you either put your name on it, and risk future censorship, or leave it unsigned, and risk being totally ignored. I think this is only going to be of any value if postings are signed.
When are people going to realize that TCP-connection based information serving doesn't scale? HTTP, BitTorrent, neither of them stand a chance against a huge number of clients.
This is a job for IP Multicast. Set up "broadcasters" (actually multicasters, obviously) pushing out the data on a fixed schedule, the way video-on-demand (yet another misnomer) works. Use trackers to allow clients to find a multicast group carrying the feed they want at a speed close to their line speed, with a start-time within a particular window around "now". Presto, each information provider only needs to transmit a small number of copies of the data, instead of one copy per requesting client. Overall Internet bandwidth requirements decrease, while everybody gets the data they're looking for at best possible speed.
Sadly, my experience echoes yours. And seeing how the software I spend most of my time working on has only a lowly command line interface, I guess it'll be some time before we see any CIOs enthusiastically dumping it on their beleaguered IT staff. It's tough to be an engineer emphasizing function over form in such a superficial world.
(Me, I read the issues lists and defer screen shots. Eventually I get to analyzing whether the menus and layouts make sense to me, but that comes long after "does it do what I need, at all?")
You don't have to shoot down a GPS satellite to confuse a GPS receiver. All you need are a couple well-synchronized transmitters with some forged signals. The algorithm used by xntpd/tickadj is sufficient for *introducing* imperceptible drift into the timecode.
Of course, you might have a problem deploying your transmitters near enough to a Navy vessel to be effective, unless you happen to have your own LEO satellites, carrying otherwise legitimate earthbound communication/TV/etc....
I wanted to model the characteristics of a turbocharger I was planning to install in my car. It seemed to me a spreadsheet was the ideal way to try various scenarios. Of course, modeling a turbo requires entering lots of lists of numbers. I had to fight with it, but despite my years of programming experience, figuring out Excel was easier and faster than writing my own custom app for the job.
Turbocharger Spreadsheet
Now I can just enter engine size, compression ratios, etc., select from a variety of compressor maps, and presto - power curves computed without breaking a sweat.
The motivation for my work in 1991 was not much different than this, although back then my problem was building the X11 distro, and all of the imake crap that was in there. Since the paper itself is no longer online, a brief summary:
- imake sucks. In the X11R4 distro, imake-generated Makefiles accounted for 11% of the disk space consumed by the source tree.
- using extra CPUs for compilation is goodness.
- Anybody with half a brain can write a better Makefile than imake produces, they just have to be bothered to do it.
- Don't use for-loops to spawn recursive make's in subdirectories when there are no serial dependencies betwen those directories. This creates serialization points that bottleneck a parallel make needlessly.
- On the flip side, don't write dependencies in a flat list when one element of the list depends on an earlier item in the list. When a parallel Make comes along and spawns them all of simultaneously, things will break.
-
In other words, always write your Makefiles such that the written dependencies reflect reality. Don't write
Nice to see that people are finally catching on, after only 13 years.- a: b c d
if 'd' depends on 'b' or 'c'.I don't think I have any time at the moment to help out. But for the moment, I'm happy to think about what such a game might do.
re: game balance, and worlds where powerful magic items are plentiful/mundane vs worlds where they are scarce - perhaps we should take another step back. Treat GMing/world design as another player type, with bonuses and advancement for passing certain milestones. Have the game system allocate limited resources to each world, e.g. "you can define as many cool artifacts as you like, as long as the code fits in 64K." As the world progresses thru X number of players per Y period of time, the GM advances to a new level, earning more resources to use in developing the world.
This kinda says that items are unique, and once removed from your world they never reappear, which could be a drag. But figuring out when to recycle things will be a challenge... If some powerful party comes thru and slaughters everything in your dungeon, taking away all the treasure, you're kind of SOL.
But somewhere in here may be a workable idea, where the GM/world evolves and advances along with the players. It would be a bit like GodWars or somesuch.
Yep, all true.
PS, I've flown in one.
http://www.highlandsun.com/hyc/blakbird.jpg
Must be.
One of the principle benefits of The Internet has been the previously-unknown ability to easily connect to people independent of their geographical location.
So now this "invention" tries to create "geography dependent" networking. Duh, we call that a "LAN". The idea is as old as networking itself; LANs have existed and been used for meaningful work long before The Internet came around. This is just the same old LAN slightly warmed over.
Now personally, if I were wandering down the street, I would probably rather *speak* to the people I run into and wanted to interact with. It's a helluva lot faster than typing, and nothing beats face-to-face interaction for high bandwidth low-latency communication.
Again, the point of The Internet was to bring people together who otherwise had no other means to interact. When you're in the same room with a bunch of other people, you have many far superior channels at your disposal.
As for the wandering store-and-forward mail-server/filedrop/whatever. This is like copying a file to a floppy disk and walking down the hall to the next computer, we called this "sneakernet" - again, not a new idea. The implementation may be a little slicker now, being wireless and so not requiring physical access. But in actual utility, you haven't gained much.
Everyone knows the maximum range specs for 802.11 are under perfect conditions with no sunspot activity, etc., and in The Real World your range is far more limited. You don't get to surreptitiously walk through a crowd and disseminate tons of information undetectably - there's a non-trivial connect-time, and anything that takes longer than a few seconds to transfer is going to be obvious. People are going to need to walk the same direction as you in a crowd. They're going to have to stay close to you to avoid signal fade from intervening objects or people, and/or they're going to have to have their own diversity antennas. Everyone will stick out plainly, and anyone who cares to monitor/surveil these people will have an easy job of it.
I really really love neat new gadgets and cool uses of technology, but this is not neat, new, cool, or useful.
There's probably not much point in responding to ACs but you're an idiot. GEM was already a mature windowing environment by 1989.
I have on my desk (even now) an Atari TT built in 1989 that ran rings around any MS/Intel box of the same vintage. 32 MHz 68030 with a 64-bit memory bus and speed to burn. What year did PCs start using 64-bit memory buses?
The simple fact that your feeble mind is only capable of comparing things in terms of Microsoft products completely proves my point.
I'm not sure what to think of that. PCs have always been cheap, compared to the alternatives (Sun/DEC/Apollo workstations). Unix on PCs was already a reality (BSDi, NetBSD) long before Linux existed. The fact that a free BSD distro never took over the hacking world the way Linux has tells me there's another factor...
That's interesting. I contributed to the codebase on a regular basis, throughout 1.0 to 1.6. Of course, I also maintained the Atari ST port.