...I was just trying to find something like this recently. I wanted something that would mostly stay put, run off AC, and use a real monitor...but that was also *quiet* and small enough to move around occasionally. Various small-form-factor PCs would fit the bill, but so would a laptop would a broken display, so I actually got as far as seeing if I could find one for sale. Now there's a third option.
Actually, the people who design ad-hoc routing protocols are very much aware of this issue. If there's an alternative route through plugged-in stations, it will be preferred. If your battery power, as reported through the routing protocol, is low, traffic will be routed somewhere else if possible. Sometimes, though, you might be the only link between two network segments, and there's no choice but to route through you. You don't even know whether that's the case, but that's the risk you have to be willing to take as the cost of participating in such a network. If you want guarantees, you can always use a traditional "infrastructure mode" AP setup that's under your own complete control.
Re:Encrypted File System
on
Storage Security
·
· Score: 2, Interesting
Yes, it's a common feature on Windows 2000 on, Linux, etc. Google can help.
it was outperformed by the P200/MMX I wanted to replace.
That seems like a rather extreme case, and probably more to do with memory than with the actual processor. On most applications, using similar memory/bus technology, the VIA will come in only a little behind an Intel or AMD processor at the same clock rate. On the measure of "MIPS per milliwatt" it will come out way ahead, and that often matters even more. This is not a platform designed for raw performance. It's designed to balance performance with other factors, and does it quite well.
Why cluster 4 of those? I'd think a 2 gig Celeron (of course P4 would be preferred) would have more power, faster DDR Ram, be as cheap (if not cheaper).
Also more power required, more heat, and more space. The nice thing about the Eden boards is that they do well in those three areas, which are more important in this application than raw computes, and yet they run everything that those hotter, more power-hungry processors plugged into bigger motherboards do. There are four of them because this is the sort of application where more slower processors provide benefits that fewer faster ones would not.
My quibble is not that they went with Eden, but that they didn't get the ME6000 which can run fanless. BTW, that board supports DDR SDRAM, so for a memory-bandwidth-bound application such as your squid server it would probably do quite well (assuming that the app isn't poorly coded to use more CPU cycles than necessary).
Disclaimer: I do have a VIA-based system (Shuttle SV24) but that's my only association with them. I also happen to know a couple of the Wifi Caravan folks.
If that packet is going north or northwest anyway, send it north!
I didn't say it was going northwest; it was going northeast, and the shortest route would have been "straight across my network". That's all besides the fact that real networks don't have such simple geometry, so line algorithms are utterly irrelevant.
The fact is, most cases are going to be handled as efficiently as they would have been in a more "friendly" environment.
If only. The whole point is that it's not handled that way. Did you look up from your graphics-algorithm textbook to read what I actually wrote?
The problem is not that service providers pick the route that gets the packet to its destination quickest; it's that they pick the route that gets the packet off their network the fastest. Those two are not the same thing at all. Think about it geographically. Let's say I'm a square network and I receive a packet at the northern end of my western border destined for somewhere to my northeast. I know that the quickest way to get it to its destination is to move it east across my own network and deliver it to my eastern neighbor. However, I also know that if I pass it on to my northern neighbor it will still get there without coming to me again, and my northern neighbor is closer. So, if I'm a selfish bastard, what do I do? I ship it northward, minimizing the time that it spends on my own network but increasing the total time before it reaches its destination. If everyone does this same sort of "hot potato" routing, total load on the network increases for everyone. In fact, my northern neighbor might very well be doing the same for packets lying to our southwest. We'd both be better off if we'd "play nice" but since we're both trying to be selfish we both lose.
what if the person who's holding your backup copies gets tired of giving up disk storage and just deletes the software from his/her computer
That's the same as a simple failure, which the software is designed to handle anyway. What's not clear from the documentation (and I'm too pressed for time to read the code right now) is whether it does The Right Thing when a peer comes back.
If the "very large company" was a dot-bomb, though, would you have the same qualms?
That's a really good question. My gut reaction is to say that I would still refuse to look at it, but perhaps not take quite a hard line wrt terminating the interview process. Somebody else probably still owns that code but it is possible that the applicant believes or knows the code has been well and truly abandoned with no realistic possibility of its putative owner being affected by the disclosure of secrets they never cared about, and the code may be the only thing they have after generally getting screwed. Does that matter? Only a very tiny bit; not enough to justify the disclosure itself, but perhaps enough to justify giving the person a second chance. There's a difference between someone whose ethical judgment is compromised by anger or desperation and someone who calculatingly does something they know is blatantly white-and-black wrong.
Or perhaps that's a totally bogus distinction. As I said, I would still refuse to examine the sample and I would make it clear that presenting it was a serious error. It just might not be enough, all by itself, to kill the interview.
Re:Doubtful
on
Immortal Code
·
· Score: 4, Insightful
Good for you. Just last week a guy I was interviewing showed me (unasked) a spec he'd done, as a sample of his work. The copyright/confidentiality notice for a very large company was clearly printed right across the top. Needless to say, I told him to put it away and made sure he progressed no further through the interview process. I'm all for people distributing their own code freely, but I can't condone giving away someone else's trade secrets.
I know a lot of people (including me) that would be happy to improve his research code into something useful for the community at large.
I'm sure a lot of people would say the same about any piece of software, but who coordinates the patches? Who writes docs or, in the absence of docs, fields endless emails from people with questions? Releasing software implies a time commitment that the author might not be willing to make; it would certainly be nice if he did so, but nobody has a right to demand it of him.
I remember a paper describing a gcc extension to write semantic checks (for instance, reenable interrupts after disabling them). This program found an amazing number of bugs in the linux kernel.
That tool was called Metal, and it was by the same guy. His success in finding and reporting those hundreds of bugs already represents a greater contribution to Linux than all but a few could ever dream of.
unlike you, this piece of code was probably written by an experienced guy that has actually written code for parallel systems before.
I suggest you check out Dawson Engler's resume; he has almost certainly done 10x more parallel-systems development than you have. This particular code example might be a bad one, because the analysis that supports the author's conclusion is omitted from the article, but the basic point is still valid: code that contains duplicate condition checks like those in the example is more likely to contain real bugs than less duplicative code, and the "low-hanging fruit" can be identified automatically. It's not hard at all to see how deeper analysis, different rules, or annotation could do a better job of weeding out false duplicates without compromising the tool's ability to flag legitimate areas of concern.
You're arguing about low-level implementation, when the author was trying to make a point about a high-level principle. That's the hallmark of an insecure junior programmer.
If I can connect to my fixed storage from nearly anywhere, why do I need to carry yet another piece of hardware?
That's actually a very good question. However, there's also a really good answer: bandwidth. Sure, you might be doing OK for most things if you're in an 802.11b (or, better yet, 802.11g) hotspot, but not if you're doing anything I/O intensive (like high-res media). Cellular bandwidth isn't going to be truly sufficient even for light storage I/O any time soon, and there will always be some blackout times or areas.
Sure, you say, so you use a local disk as a fast cache to avoid going over the net for every single block, but the authoritative copy (or copies) is still "out there" rather than on your laptop. It just so happens I've done a few years' work in exactly that area, and here's the thing: that cache needs to be fairly large, and it needs to be fairly fast, so you're back to needing some sort of reasonably high-capacity high-bandwidth local storage in a small form factor. That's why something like this would still be useful.
That's the only explanation that makes sense. He's trying to discredit MS-bashers by providing such an excellent example of false and childish anti-MS claims. The original @Stake paper (don't blame me for the format) not only lists vulnerable Linux drivers, it seems to list only Linux drivers. Windows is mentioned exactly once, and only in a vague afterthought kind of way; the focus is on the vulnerability as it exists on Your Favorite OS.
I don't know anyone who is a language guru who is not otherwise intelligent and versed in at least some of the conceptual stuff.
I've met plenty of language lawyers (and STL addicts) who really couldn't develop or even analyze an algorithm for themselves, but can only think of ways to reuse what has already been handed to them. Stick around for a while, you'll meet them too.
"The STL is god. Worship the STL, mere mortals." Excuse me while I barf. STL is the worst example I've yet seen in common use of the overdesign that can occur from people spending too much time in CS seminars and not enough time writing something people can actually use. A good API doesn't go out of its way to use every obscure language feature, or demand that users spend weeks or months getting used to the author's coding style, just to do simple stuff like strings and containers. It doesn't have crap like auto_ptr, which is like pointers in only one way but unlike them in many others. That's a leaky abstraction and bad reuse, which is almost as much of a problem as foregoing good reuse.
If everyone reused the standard APIs in an intelligent way instead of redesigning them incorrectly, they might actually get some code out the door.
That's great if what you're writing is totally derivative, but innovative code doesn't get written by sitting around and thinking about how to maximize reuse of existing APIs.
No, perl is the de facto standard used by newbies and children who don't want to learn a real language. Anybody who offers perl as an example of a real language doesn't know shit. It's awk with extra cruft.
Lighten up. The grandparent was at least half a joke, and I - like anyone who has grumbled in the past about C/C++/Java's overloading of one reserved word to mean many different things - found it pretty amusing.
There is only one meaning for protected
Really? Consider the following:
class foo: protected bar { protected: int ugh; };
Note how the two occurrences of "protected" don't have anything like the same meaning. As I just said, this overloading of reserved words is annoying, and deserves to be made fun of.
For the first time you have a true alternative to the hierarchical file system at the OS level. Through the modification of the KDE shared libraries, newdocms currently works with all KDE apps!
Shared-library hacks are not "the OS level" even if you're talking about libc, and even less so for something KDE-specific.
this sort of innovation could never happen if it weren't for the free software nature of the underlying systems."
Wrong again. At least five years ago I was using a Windows shell extension that let me attach metadata to files and search by metadata. I don't remember the name off the top of my head, but it was similar to Explorer Notes or FileNotes or Annotater. Sure, those only work in Explorer, but that's no worse than only working in KDE. Far from being a "free-software innovation" this is something that's been kicking around for ages in the non-free world and the free-software version is (as usual) pretty late on the scene.
Here's a clue, "buddy": not all technologies have the same life cycle, and in general tech life cycles have been decreasing. Your apples-and-oranges comparison is utterly worthless, like you.
It's not too hard to find a modern tape drive for about three hundred bucks that will sustain 2 MB/s (equivalent to 12x) and store 20GB per cartridge (equivalent to 30 CD-Rs). That hardly seems to fit your image of "slow and very expensive".
Most home users don't do tape backups.
Utterly irrelevant. The reason has more to do with the convenience of random access (which, I admit, is a compelling feature) than anything we're talking about.
Tapes are absolutely not good long-term storage.
Please, study the work done by professional archivists and such. Manufacturer's claims are worthless. When we're talking about home users, "ideal conditions" studies are almost as bad. From what I've seen, the life expectancy of a CD-R under typical conditions is about two years; for tape it's two to five. CD-RW and all flavors of writable DVD are even less durable.
All that said, I'm not saying there's anything wrong with using optical media for backup. I do so myself. What I said is that it's not what they're *for* - i.e. not *designed* for. CD and DVD formats were designed for distribution, and recordable versions originally for copying, but backup is neither of those. MO is actually the most durable type of storage that's anywhere near affordable (ion-beam-etched nickel plates don't count) and could be said to've been designed for backup, but media are expensive and I don't think that's what you were talking about.
Hmmm. I wonder why there's no MO tape. Seems like it'd be extremely durable with a reasonable media cost. Maybe nobody's come up with a flexible MO material/coating.
I don't think backward compatibility to current DVD technology is going to count for a lot in 2010 because nobody will be using current DVD technology (for data) by then. Backwards compatibility with Blu-ray, or its successor, or whatever comes along and supplants both five years from now, is what will really matter. Compatibility with a by-then obsolete standard will actually turn out to be a handicap in 2010, and they probably know that, but here in 2002 maybe it helps them get funding.
Slashdot Mirror
...I was just trying to find something like this recently. I wanted something that would mostly stay put, run off AC, and use a real monitor...but that was also *quiet* and small enough to move around occasionally. Various small-form-factor PCs would fit the bill, but so would a laptop would a broken display, so I actually got as far as seeing if I could find one for sale. Now there's a third option.
Actually, the people who design ad-hoc routing protocols are very much aware of this issue. If there's an alternative route through plugged-in stations, it will be preferred. If your battery power, as reported through the routing protocol, is low, traffic will be routed somewhere else if possible. Sometimes, though, you might be the only link between two network segments, and there's no choice but to route through you. You don't even know whether that's the case, but that's the risk you have to be willing to take as the cost of participating in such a network. If you want guarantees, you can always use a traditional "infrastructure mode" AP setup that's under your own complete control.
Yes, it's a common feature on Windows 2000 on, Linux, etc. Google can help.
That seems like a rather extreme case, and probably more to do with memory than with the actual processor. On most applications, using similar memory/bus technology, the VIA will come in only a little behind an Intel or AMD processor at the same clock rate. On the measure of "MIPS per milliwatt" it will come out way ahead, and that often matters even more. This is not a platform designed for raw performance. It's designed to balance performance with other factors, and does it quite well.
Also more power required, more heat, and more space. The nice thing about the Eden boards is that they do well in those three areas, which are more important in this application than raw computes, and yet they run everything that those hotter, more power-hungry processors plugged into bigger motherboards do. There are four of them because this is the sort of application where more slower processors provide benefits that fewer faster ones would not.
My quibble is not that they went with Eden, but that they didn't get the ME6000 which can run fanless. BTW, that board supports DDR SDRAM, so for a memory-bandwidth-bound application such as your squid server it would probably do quite well (assuming that the app isn't poorly coded to use more CPU cycles than necessary).
Disclaimer: I do have a VIA-based system (Shuttle SV24) but that's my only association with them. I also happen to know a couple of the Wifi Caravan folks.
I didn't say it was going northwest; it was going northeast, and the shortest route would have been "straight across my network". That's all besides the fact that real networks don't have such simple geometry, so line algorithms are utterly irrelevant.
If only. The whole point is that it's not handled that way. Did you look up from your graphics-algorithm textbook to read what I actually wrote?
The problem is not that service providers pick the route that gets the packet to its destination quickest; it's that they pick the route that gets the packet off their network the fastest. Those two are not the same thing at all. Think about it geographically. Let's say I'm a square network and I receive a packet at the northern end of my western border destined for somewhere to my northeast. I know that the quickest way to get it to its destination is to move it east across my own network and deliver it to my eastern neighbor. However, I also know that if I pass it on to my northern neighbor it will still get there without coming to me again, and my northern neighbor is closer. So, if I'm a selfish bastard, what do I do? I ship it northward, minimizing the time that it spends on my own network but increasing the total time before it reaches its destination. If everyone does this same sort of "hot potato" routing, total load on the network increases for everyone. In fact, my northern neighbor might very well be doing the same for packets lying to our southwest. We'd both be better off if we'd "play nice" but since we're both trying to be selfish we both lose.
Yes, folks, it's an instance of the prisoners' dilemma and these researchers are not the first to notice the fact.
That's the same as a simple failure, which the software is designed to handle anyway. What's not clear from the documentation (and I'm too pressed for time to read the code right now) is whether it does The Right Thing when a peer comes back.
FireWire is 1394, not 1392.
That's a really good question. My gut reaction is to say that I would still refuse to look at it, but perhaps not take quite a hard line wrt terminating the interview process. Somebody else probably still owns that code but it is possible that the applicant believes or knows the code has been well and truly abandoned with no realistic possibility of its putative owner being affected by the disclosure of secrets they never cared about, and the code may be the only thing they have after generally getting screwed. Does that matter? Only a very tiny bit; not enough to justify the disclosure itself, but perhaps enough to justify giving the person a second chance. There's a difference between someone whose ethical judgment is compromised by anger or desperation and someone who calculatingly does something they know is blatantly white-and-black wrong.
Or perhaps that's a totally bogus distinction. As I said, I would still refuse to examine the sample and I would make it clear that presenting it was a serious error. It just might not be enough, all by itself, to kill the interview.
Good for you. Just last week a guy I was interviewing showed me (unasked) a spec he'd done, as a sample of his work. The copyright/confidentiality notice for a very large company was clearly printed right across the top. Needless to say, I told him to put it away and made sure he progressed no further through the interview process. I'm all for people distributing their own code freely, but I can't condone giving away someone else's trade secrets.
I'm sure a lot of people would say the same about any piece of software, but who coordinates the patches? Who writes docs or, in the absence of docs, fields endless emails from people with questions? Releasing software implies a time commitment that the author might not be willing to make; it would certainly be nice if he did so, but nobody has a right to demand it of him.
That tool was called Metal, and it was by the same guy. His success in finding and reporting those hundreds of bugs already represents a greater contribution to Linux than all but a few could ever dream of.
I suggest you check out Dawson Engler's resume; he has almost certainly done 10x more parallel-systems development than you have. This particular code example might be a bad one, because the analysis that supports the author's conclusion is omitted from the article, but the basic point is still valid: code that contains duplicate condition checks like those in the example is more likely to contain real bugs than less duplicative code, and the "low-hanging fruit" can be identified automatically. It's not hard at all to see how deeper analysis, different rules, or annotation could do a better job of weeding out false duplicates without compromising the tool's ability to flag legitimate areas of concern.
You're arguing about low-level implementation, when the author was trying to make a point about a high-level principle. That's the hallmark of an insecure junior programmer.
That's actually a very good question. However, there's also a really good answer: bandwidth. Sure, you might be doing OK for most things if you're in an 802.11b (or, better yet, 802.11g) hotspot, but not if you're doing anything I/O intensive (like high-res media). Cellular bandwidth isn't going to be truly sufficient even for light storage I/O any time soon, and there will always be some blackout times or areas.
Sure, you say, so you use a local disk as a fast cache to avoid going over the net for every single block, but the authoritative copy (or copies) is still "out there" rather than on your laptop. It just so happens I've done a few years' work in exactly that area, and here's the thing: that cache needs to be fairly large, and it needs to be fairly fast, so you're back to needing some sort of reasonably high-capacity high-bandwidth local storage in a small form factor. That's why something like this would still be useful.
That's the only explanation that makes sense. He's trying to discredit MS-bashers by providing such an excellent example of false and childish anti-MS claims. The original @Stake paper (don't blame me for the format) not only lists vulnerable Linux drivers, it seems to list only Linux drivers. Windows is mentioned exactly once, and only in a vague afterthought kind of way; the focus is on the vulnerability as it exists on Your Favorite OS.
I've met plenty of language lawyers (and STL addicts) who really couldn't develop or even analyze an algorithm for themselves, but can only think of ways to reuse what has already been handed to them. Stick around for a while, you'll meet them too.
"The STL is god. Worship the STL, mere mortals." Excuse me while I barf. STL is the worst example I've yet seen in common use of the overdesign that can occur from people spending too much time in CS seminars and not enough time writing something people can actually use. A good API doesn't go out of its way to use every obscure language feature, or demand that users spend weeks or months getting used to the author's coding style, just to do simple stuff like strings and containers. It doesn't have crap like auto_ptr, which is like pointers in only one way but unlike them in many others. That's a leaky abstraction and bad reuse, which is almost as much of a problem as foregoing good reuse.
That's great if what you're writing is totally derivative, but innovative code doesn't get written by sitting around and thinking about how to maximize reuse of existing APIs.
No, perl is the de facto standard used by newbies and children who don't want to learn a real language. Anybody who offers perl as an example of a real language doesn't know shit. It's awk with extra cruft.
Piss off. I've read 'em, they say exactly the opposite of what you're saying. You're just one of those people who can never admit you're wrong.
Lighten up. The grandparent was at least half a joke, and I - like anyone who has grumbled in the past about C/C++/Java's overloading of one reserved word to mean many different things - found it pretty amusing.
Really? Consider the following:
Note how the two occurrences of "protected" don't have anything like the same meaning. As I just said, this overloading of reserved words is annoying, and deserves to be made fun of.
Shared-library hacks are not "the OS level" even if you're talking about libc, and even less so for something KDE-specific.
Wrong again. At least five years ago I was using a Windows shell extension that let me attach metadata to files and search by metadata. I don't remember the name off the top of my head, but it was similar to Explorer Notes or FileNotes or Annotater. Sure, those only work in Explorer, but that's no worse than only working in KDE. Far from being a "free-software innovation" this is something that's been kicking around for ages in the non-free world and the free-software version is (as usual) pretty late on the scene.
Sounds like child abuse to me.
Here's a clue, "buddy": not all technologies have the same life cycle, and in general tech life cycles have been decreasing. Your apples-and-oranges comparison is utterly worthless, like you.
It's not too hard to find a modern tape drive for about three hundred bucks that will sustain 2 MB/s (equivalent to 12x) and store 20GB per cartridge (equivalent to 30 CD-Rs). That hardly seems to fit your image of "slow and very expensive".
Utterly irrelevant. The reason has more to do with the convenience of random access (which, I admit, is a compelling feature) than anything we're talking about.
Please, study the work done by professional archivists and such. Manufacturer's claims are worthless. When we're talking about home users, "ideal conditions" studies are almost as bad. From what I've seen, the life expectancy of a CD-R under typical conditions is about two years; for tape it's two to five. CD-RW and all flavors of writable DVD are even less durable.
All that said, I'm not saying there's anything wrong with using optical media for backup. I do so myself. What I said is that it's not what they're *for* - i.e. not *designed* for. CD and DVD formats were designed for distribution, and recordable versions originally for copying, but backup is neither of those. MO is actually the most durable type of storage that's anywhere near affordable (ion-beam-etched nickel plates don't count) and could be said to've been designed for backup, but media are expensive and I don't think that's what you were talking about.
Hmmm. I wonder why there's no MO tape. Seems like it'd be extremely durable with a reasonable media cost. Maybe nobody's come up with a flexible MO material/coating.
I don't think backward compatibility to current DVD technology is going to count for a lot in 2010 because nobody will be using current DVD technology (for data) by then. Backwards compatibility with Blu-ray, or its successor, or whatever comes along and supplants both five years from now, is what will really matter. Compatibility with a by-then obsolete standard will actually turn out to be a handicap in 2010, and they probably know that, but here in 2002 maybe it helps them get funding.