Our results showed that 50% of the root server traffic comes from only 220 IP addresses.
List, please? Hey Bush, forget about Iraq, let's take these bastards out. [grabs ak-47]
Remember that some of those are perfectly legitimate. Huge ISP's like AOL should be funneling all of their customers queries from a small number of IP addresses. That's the whole point. On the other hand, some of these are probably losers who are doing dictionary searches on domain names. You are likely to get blacklisted from the Whois servers if you try that. You won't get blacklisted from the DNS servers, it appears. But it should be easy to tell the difference between legitimate query streams and illegitimate ones.
Actually, most War On (Some)Drugs supporters could tell you that with a straight face and not bat an eyelash. Most of them could then go on and tell you that any innocent Iraqi's killed by American bombs are actually Hussein's responsibility, and conclude by explaining that victims of spouse abuse are responsible for their plight because a good beating was the only response to their poor behavior.
Of course he was talking about the ivory tower of PERL
PERL is an ivory tower? Wow, that must've been some flame war. Last I checked Perl stood for "Practical Extraction and Report Language", and I'm pretty sure that "Practical" is not a member of the set "Ivory Tower". It's a great quote, I just wouldn't every guess is was about Perl and Tcl. x86 vs. RISC maybe. But not Perl, unless you consider it one of the hordes.:-)
But remember, they aren't watching the traffic of the folks suspected of copyright violations. They are watching everybody's traffic. That's why this has so many people up in arms. To use your example, can I put a camera in your house because somebody robbed my house? Robbery is illegal you know, I don't know why you think you have a right to privacy. As long as you aren't the burglar, you have nothing to fear from my surveillance camera. Right?
But were these phone companies really in enough financial trouble to justify this rule-change?
Given that the affected Baby Bell's stock prices have all fallen today, I'm not sure this ruling is necessarily going to help them much. At least Wall Street doesn't seem to think so. My personal favorite, Qwest, is actually down like 13%. With any luck they'll go bankrupt by the end of the week.
I think all the Bells are in for a rough future. They only ever made money in the urban areas anyway, all those rural lines lose money. But the urban folks are starting to have real options. What with ubiquitous cell phone coverage and cable companies offering voice service, a huge number of folks don't need the phone company for that at all. Add in cable broadband and wireless ISP's for data service, and the Bells have real competition. Something which they aren't very good at dealing with, witness the way they begged the FCC into this most recent ruling.
I think whoever wrote this article is far removed from the real world. They are finding theoretical problems with the routing protocols we would like to be running. As you pointed out, pretty much the entire backbone is using BGP4 to make routing decisions. And BGP4 doesn't really have any measure of how congested links are, nor how long the latency is. The basic measure of BGP4 is how many different providers (called AS's or Autonomous Systems) a packet might have to traverse.
Hmmm, the router says, is the best route thru C&W->AT&T->Bob's_ISP or just Level3->Bob's_ISP? I'll pick the two hop route. Sure, we all do some manual tuning, where the engineer says "I know the L3->Bob link is slow, so I'll make it look like L3->L3->Bob", but BGP4 is fundamentally a really stupid protocol. In theory. In practice, it works fine almost all of the time.
The most telling quote from the article is this:
They also found that doubling the capacity of the system would provide the same benefits as a managed system.
No shit Sherlock. I could've told you that five years ago. Why do you think QoS is still facing an uphill struggle? It's far cheaper and easier to just keep cranking up the bandwidth than to replace BGP4 with something smarter, or to deploy QoS protocols Internet wide.
Don't get me wrong, I think they are doing great research. It's good to try and figure out what might go wrong with next-gen protocols before the get deployed. But I don't think they are talking about problems on todays Internet.
So in conclusion, Linux's current view of files is not incompatible with metadata, and there are many advantages to viewing files in the way that Linux does.
Sure, but having additional metadata does not prevent things from working the way they do under Linux. In fact, for most things, BeOS looked just like any other Posix system. Devices were files, and all the standard Posix read/write calls were there. There were downsides, of course. You could accidentally trash the metadata if you weren't careful. The 'cp' command, for example, didn't copy the metadata (which I consider to be a bug, but oh well). And of course if you used FTP or something to copy files around it got lost. It wasn't hopeless, of course. If you copied files in the tracker, it did the right thing. And all the zip/unzip binaries for BeOS maintained the attributes so you could safely move the files between systems.
So the two can co-exist. In fact, there is a filesystem driver for BFS in the kernel now. Last I looked, but was read-only. But it's certainly possible for it to become read-write and for the whole index/attribute API to become available under Linux. You would have the same risks as under BeOS (tar,cp,scp,etc. would lose the metadata), but even that could be fixed. 'cp' can already be told to preserve the metadata it knows about. 'tar' is a lost cause because you'd probably have to try and change the file format which wouldn't go over very well.
I'll read the white paper on reiserfs you linked. Maybe it'll end up providing some of the stuff I want.
Wow, that's a pretty good idea. Maybe somebody could code up a simple hack with your idea and somebody elses mention of XFS. Use XFS to store filetypes and possibly custom application handlers for files. And then a little "open" script which uses various information to find an application which can handle it. If you have a filetype already for the file, use it. If not, run 'file -i' to try and determine one. If that also fails, try to go by the extension. If that fails, error or open the file in a hex editor:-)
Under BeOS it was a library call, but a lot of things in *nix land are small programs instead of libraries. I wonder if anybody has already hacked something similar up?
The extended attributes would be a good place to put some stuff. Like filetypes, for example. By default BeOS didn't index those, and there isn't much need to. Due to the way the indexes were implemented, it would have been horribly slow anyway. So XFS might work well for that, or custom icons, or custom application bindings. There are quite a few things which are handy to keep track of about a file which are independant of it's contents or format.
But without the indexes, the attributes aren't useful for search-oriented actions. In my case, I really abuse the ability to search in my jukebox software. But since both MP3 and Ogg Vorbis include ways to store metadata in the stream itself, XFS doesn't add much benefit.
in-file metadata is fine for some purposes. If you want to keep your metadata intact as you moves the files around from system to system, it works well for that purpose. And if you just want your player to be able to pretty print the song information, it's fine.
But what about when I want to search the metadata in all of my songs? I've got something like 10GB of Ogg's. A majority of my music collection. Should the player search every file every time I do a query? No, that's ridiculous of course. Should I have the player scan every single song when it starts up and cache the infomation? Maybe if you don't mind reaaaly slow startup times. No, the place to keep that much information if you want to search it is in a database. And that's what BeOS did, in a nice simple standardized API. Oh, and did I mention that the queries can be live under BeOS? So if files are added or deleted which match an active query my application gets informed? There isn't really any way to replicate that with just ID3 tags without either polling (expensive) or kernel mods (which have their own development headaches.)
I too am at a loss to describe any existing problem which BeOS solves.
How about decent file typing? That's one thing BeOS did well, using MIME as the native file typing mechanism. MacOS had pretty good file types, but Apple seems to be discouraging it's use in favor of the lowest common denominator: file extensions. Which are frankly, crap.
Linux is probably at the bottom of the heap here. Both Gnome and KDE are starting to maintain their own databases of this stuff, which is pointless because this should be a common service OS-wide. An application should be able to ask the OS which application should be called to handle text/html for example. But there isn't any standard way to do that on Linux. As a result, different applications do different things when I click on a link. I want a Konq window to open, but there isn't any way for me to tell Evolution that. It insists on opening a Mozilla window.
I'm sure eventually this will get solved on Linux, but BeOS was handling this problem quite well five years ago. It isn't rocket science, in fact it's pretty simple.
Another example is file metadata. BeOS allowed you to add arbitrary name/value attributes to files. What's more, you could have the filesystem index them to allow you to do quick searches on them. Plus the Tracker allowed you to specify what attributes you wanted to have displayed in folder windows. You didn't have to look at the file name and size if you didn't want to. You could view only custom metadata.
This works great for audio files. The developers standarized on a set of attributes which all the major MP3 applications use. So all of my MP3 (well, Ogg actually) files have the artist, album, track, etc saved as metadata. The Tracker can be told to only display those attributes, if you want. Plus the OS can search on them. I've got a ripper thats adds the attributes when I rip a CD. I've got a file viewer, the Tracker, which lets me sift thru my collection looking at the relevant metadata. And I've got a player which lets me add file, folders, and arbitrary metadata queries to playlists.
Unfortunately, having my jukebox based on a dead OS is getting to be a drag for other reasons. So, I'll probably try to move the whole thing to Linux, but it'll be painful. I'll have to install my own database to handle the metadata. There's no standard schema so the few MP3 apps which do use databases won't interoperate. Not to mention that having the actual files and metadata completely disconnected is an extremely fragile solution. If you move a file using the normal techniques, then the metadata is out of sync and you have to fix it somehow. So I do what? Write my own interface for providing simple file manipulations so that I can keep the metadata in sync? That's not really practical either. In the end, I'll probably spend a lot of time implementing a solution that will work half as well.
Not that BeOS was perfect, far from it. Shall I discuss the pain of porting network software to an OS where sockets are not file descriptors? But it did have some really nice features which I have yet to find in any other OS.
Man, do I feel dumb. I don't even remember there being a Star Trek movie out over Christmas. Weird. They apparently only marketed it in media I don't pay attention to. Or maybe it's just the fact that there have been so many Star Trek movies that it just wasn't possible for my subconcious to register "Nemesis" as having an existence of it's own. Kind of like James Bond movies. My brain doesn't seem to be able to register the existence of new episodes of that series either. I'm just too damn old to waste brain cells trying to keep track of a dozen different Bond or ST flicks.
Overall it's quite a good article.
on
NARAS vs. the RIAA
·
· Score: 2, Funny
But I couldn't help but be a little put off by Prince's disrespect 4 the English languange as a means of xpression. I think I know why he hasn't released an album lately. He's been too busy hanging out in chat rooms.
he press release *seemed* to indicate that only the Athlon64 (single-processer desktop version) would be delayed, and perhaps not the Opteron (multi-CPU server version). However, it wasn't entirely clear.
So when the posted article said in the second paragraph: Opteron, in keeping with the company's original launch date, is set to officially debut on April 22 in New York City.
That wasn't clear enough for you? Only the desktop and mobile versions are being delayed. Which makes sense. The market for a 64-bit laptop right now is pretty slim. But I think AMD will probably make the April release date. Opteron servers are actually shipping now in limited quantities to beta evaluators. And I actually touched a Linux-running, working, Opteron server at a conference last November. These things are a long way from being vapor. I'm betting that AMD just wants to be super careful since the server market is not very tolerant of crappy hardware.
I've been told that it'll be about a 20% hit to access the memory on the wrong processor. I haven't actually seen any benchmarks or anything, but that's what a guy in the AMD booth at Supercomputing '02 said.
Then watch as every e-mail from a windows user comes encrypted with a Palladium-approved e-mail app required for decryption.
This simply won't happen. Even Microsoft is not dumb enough to force people to send their email in a format which can't be read by the entire existing base of Windows users.
Or watch as any media file you find/download/buy/rip on a Windows PC gets encrypted and locked to that specific PC in hardware.
Watch as I don't buy anything using a Windows PC. Just like today. Some online content is only available in Windows Media Format. I don't listen or view it.
Or watch as web sites demand to check that you're running a Palladium-enabled system before you can enter.
Watch as I don't do business with that company. Hell, there's nothing new here. There are online companies I don't do business with today for the single reason that their web page doesn't work in Konq. Build an IE only web page? I won't use it. Besides, didn't you read the article? Linux users will probably be able to make use of TCPA based security for online transactions before Microsoft Windows users.
good to see IBM on-board. They've already written GPL drivers for Linux, and are showing massive support from the very beginning -- something you rarely see with *any* new specification or proposed standards. Any Linux user should be glad IBM is on-board as well.
Damn right. I assume you saw the articles earlier this week that IBM is claiming I think $1.5 billion in Linux based revenue, and HP is claiming $2.0 billion? Linux Brings In Big Bucks That kind of money can support some pretty serious development. It's not hard to imagine that Linux will end up with the premier set of software tools which does useful things with TCPA. Sure, maybe RedHat isn't bringing in the revenue they might like, but it sounds like free software as a whole is doing pretty damn well.
Of course, they don't mention that it's more than likely that in the near future, a version of Windows will take advantage of it
And so what? If you don't like the features Microsoft(tm) puts in their operating system, don't run Windows!. It's just that easy. You don't have to wait for TCPA for Microsoft(tm) to build objectionable stuff into their OS. Their Media Player already has DRM build into it. Don't like it? Don't run it. As Nancy Reagan liked to say, "Just Say No!"
My question to you is: what use, then, does TCPA serve?
Microsoft(tm) wants to position Windows as the premier content viewing platform for digital media. One way of doing this is to get the media companies to "trust" Windows. Specifically, the media cartel want to be able to have some certainty that the end user hasn't modified the operating system from it's original state. Sure, Microsoft can include software checks but these are trivially circumvented.
Enter TCPA. The BIOS acts as a "root of trust" (their term) which can be used to verify that the operating system has not been modified by the user. The TCPA BIOS will be audited, manufactured by trustworthy companies, and not easily modified by end users. The BIOS records the hash of the bootloader, which records the hash of the operating system loader, etc. etc. The goal being to force people who want to circumvent the operating system security to use hardware cracks. Presumably that's the only way to get the media cartel to "trust" your platform. And if all the online media is only available under Windows, that's big cha-ching for Microsoft going forward. Not to mention making things like product activation much more resiliant. Isn't that reason enough?
why does Microsoft need TCPA if Microsoft is not planning to introduce features into Windows which are only available via MS-approved boot loaders? This would be an anti-competitive move, yes,
Microsoft will introduce features which are only available thru a certified bootloader. That's the whole point! You can't very well pretend that the operating system is running in a known secure state if it's running inside of VMware, now can you? But like I said, at worst that will just mean that you'll have to the Microsoft bootloader to get to LILO. A pain perhaps, but not something that is likely to be seen as anti-competetive.
Instead of getting our panties up in a knot, we should be trying to figure out how to make use of the new features TCPA will provide. Like how about a secure partition which can't be mounted/decrypted if you're computer is booted from a floppy? Or how about a distribution like Debian using this to ensure that package submissions only come from fully-patched up-to-date systems? Or for that matter, allowing clients downloading updates to verify that the server hasn't been rooted! Now that would be cool.
The TCPA standard talks a lot about the "Owner" of the system, and how the "Owner" can initialize a new system so that it will begin generating keys and such using a password set up during the "ownership" process (See Section 2.6 of the Standard). My question is: who would the "Owner" of a system normally be in plain english? The actual end-user (or their administrator)? Or would the TPM get "owned" by the hardware vendor (Dell, HP, etc.) Or the OS vendor? Or the motherboard manufacturer?
Second, will it be possible to completely reset the TPM to a non-owned state to allow used hardware to be sold "as new"? Or would the hardware refuse to allow a new owner?
If I understood the prior articles correctly, TCPA should provide... enough checking to insure that the boot sector is signed.
I'm amazed at how common this meme has become despite the fact that it is completely false. TCPA in no way dicates what code can run on the machine. The "security" it offers works in pretty much the reverse fashion. The TCPA BIOS hashes the bootloader and saves that hash in a secure place. That allows the bootloader to verify that it really did run first. The bootloader can then hash some portion of the OS, and then load and execute it. The OS can then verify that the boot process really was TCPA-BIOS->Correct bootloader->Unmodified OS. And more importantly, the OS can have the BIOS give it a cryptographic "proof" of this fact to hand to other programs or web sites.
What does this mean for Linux? Probably nothing. Linux could make use of this functionality, but my guess is it probably won't. The fact is that unless your code actually bothers to check the TCPA state of the machine, it just doesn't matter.
On the other hand, Palladium might make some things a little trickier. Since the bootloader is part of the TCPA chain of trust, it's highly unlikely that Palladium will be able to enter it's "secure" mode if you are using LILO or grub. So if you are somebody who actually dual-boots you will probably have to have an official Microsoft bootloader on/dev/hda and LILO or whatever on/dev/hda1 (for example) and have the Microsoft bootloader pass control to your Linux bootloader. Or just don't run Windows.
Could Microsoft abuse this to try to prevent users from dual booting? Sure. But they could easily prevent people from dual booting today if they wanted to. It's just that it would be such a blatantly anti-competetive move that even Microsoft would have a hard time pulling it off. They could refuse to boot thru LILO. They could complain and offer to "fix" any non-FAT or NTFS partitions at every boot. They could use browser version strings to control access to updates on their web site and bring DMCA charges against browsers which circumvent that by pretending to be IE. TCPA doesn't really make it easier to Microsoft to screw with people who dual boot. It's already trivial today!
It's probably too late for anyone to read this, but what the hell. Last night I found what I'm 90% certain is a professional pirated CD in my collection. It's a disc of Christmas carols that my wife bought at her dad's church last year. It looks professional, being silkscreened and being a pressed CD not burned. But it doesn't have a case, just a paper sleeve. What really tipped my off is that when I asked my ripper to identify it freedb.org, I got back a different title!. Identical tracks. Identical lengths. Identical songs. But a totally different (and more generic) title. When I looked more closely at the CD, I realized that it had no indication of copyright at all! "What the hell???", I thought.
I may have to try and buy the legit version of the CD and show 'em both to my father-in-law next time I see him. I can't decide if I'm appaled or amused by the thought of some guy making thousands of pirated CDs and selling them to churches to use as a fund-raising item. I guess it's typical. You're average church-goer is the kind of person who would wander from house to house publicly performing copyrighted works without paying royalties anyway.
And those are from charities, time-warner cable (since we already have a "business relationship" with them)
Just tell time-warner to put you on their do not call list, and that if they call again you're going to cancel your service and get DirectTV or something. I used to get calls from both Qwest (my phone company) and MBNA (credit card), but neither one has called for quite some time after I told them that they would lose me as a customer if they called again. FWIW, I'm also on Colorado's do not call list. I think I've gotten maybe one commercial telemarketer call since the list went into effect about six months ago. I'm actually hoping one will call so I can sue 'em. I still get the occasional charity and politial call (around election time), but not very many.
PD's, FD's, Hospitals, etc. are all considered to be zones absolutely off limits to any such interference this would cause
So it's illegal to use 802.11b, a 2.4GHz cordless phone, or a microwave oven in the same region as a fire department, a police department, or a hospital? Quite frankly, I think you're wrong and yours is the first such claim I've heard regarding the use of unlicensed spectrum. Please provide a reference, as it appears you believe that the FCC was quite irresponsible in allowing retailers to sell such dangerous devices to the general public.
Slashdot Mirror
Our results showed that 50% of the root server traffic comes from only 220 IP addresses.
List, please? Hey Bush, forget about Iraq, let's take these bastards out. [grabs ak-47]
Remember that some of those are perfectly legitimate. Huge ISP's like AOL should be funneling all of their customers queries from a small number of IP addresses. That's the whole point. On the other hand, some of these are probably losers who are doing dictionary searches on domain names. You are likely to get blacklisted from the Whois servers if you try that. You won't get blacklisted from the DNS servers, it appears. But it should be easy to tell the difference between legitimate query streams and illegitimate ones.
Actually, most War On (Some)Drugs supporters could tell you that with a straight face and not bat an eyelash. Most of them could then go on and tell you that any innocent Iraqi's killed by American bombs are actually Hussein's responsibility, and conclude by explaining that victims of spouse abuse are responsible for their plight because a good beating was the only response to their poor behavior.
Of course he was talking about the ivory tower of PERL
:-)
PERL is an ivory tower? Wow, that must've been some flame war. Last I checked Perl stood for "Practical Extraction and Report Language", and I'm pretty sure that "Practical" is not a member of the set "Ivory Tower". It's a great quote, I just wouldn't every guess is was about Perl and Tcl. x86 vs. RISC maybe. But not Perl, unless you consider it one of the hordes.
But remember, they aren't watching the traffic of the folks suspected of copyright violations. They are watching everybody's traffic. That's why this has so many people up in arms. To use your example, can I put a camera in your house because somebody robbed my house? Robbery is illegal you know, I don't know why you think you have a right to privacy. As long as you aren't the burglar, you have nothing to fear from my surveillance camera. Right?
But were these phone companies really in enough financial trouble to justify this rule-change?
Given that the affected Baby Bell's stock prices have all fallen today, I'm not sure this ruling is necessarily going to help them much. At least Wall Street doesn't seem to think so. My personal favorite, Qwest, is actually down like 13%. With any luck they'll go bankrupt by the end of the week.
I think all the Bells are in for a rough future. They only ever made money in the urban areas anyway, all those rural lines lose money. But the urban folks are starting to have real options. What with ubiquitous cell phone coverage and cable companies offering voice service, a huge number of folks don't need the phone company for that at all. Add in cable broadband and wireless ISP's for data service, and the Bells have real competition. Something which they aren't very good at dealing with, witness the way they begged the FCC into this most recent ruling.
if I could.
I think whoever wrote this article is far removed from the real world. They are finding theoretical problems with the routing protocols we would like to be running. As you pointed out, pretty much the entire backbone is using BGP4 to make routing decisions. And BGP4 doesn't really have any measure of how congested links are, nor how long the latency is. The basic measure of BGP4 is how many different providers (called AS's or Autonomous Systems) a packet might have to traverse.
Hmmm, the router says, is the best route thru C&W->AT&T->Bob's_ISP or just Level3->Bob's_ISP? I'll pick the two hop route. Sure, we all do some manual tuning, where the engineer says "I know the L3->Bob link is slow, so I'll make it look like L3->L3->Bob", but BGP4 is fundamentally a really stupid protocol. In theory. In practice, it works fine almost all of the time.
The most telling quote from the article is this:
They also found that doubling the capacity of the system would provide the same benefits as a managed system.
No shit Sherlock. I could've told you that five years ago. Why do you think QoS is still facing an uphill struggle? It's far cheaper and easier to just keep cranking up the bandwidth than to replace BGP4 with something smarter, or to deploy QoS protocols Internet wide.
Don't get me wrong, I think they are doing great research. It's good to try and figure out what might go wrong with next-gen protocols before the get deployed. But I don't think they are talking about problems on todays Internet.
So in conclusion, Linux's current view of files is not incompatible with metadata, and there are many advantages to viewing files in the way that Linux does.
Sure, but having additional metadata does not prevent things from working the way they do under Linux. In fact, for most things, BeOS looked just like any other Posix system. Devices were files, and all the standard Posix read/write calls were there. There were downsides, of course. You could accidentally trash the metadata if you weren't careful. The 'cp' command, for example, didn't copy the metadata (which I consider to be a bug, but oh well). And of course if you used FTP or something to copy files around it got lost. It wasn't hopeless, of course. If you copied files in the tracker, it did the right thing. And all the zip/unzip binaries for BeOS maintained the attributes so you could safely move the files between systems.
So the two can co-exist. In fact, there is a filesystem driver for BFS in the kernel now. Last I looked, but was read-only. But it's certainly possible for it to become read-write and for the whole index/attribute API to become available under Linux. You would have the same risks as under BeOS (tar,cp,scp,etc. would lose the metadata), but even that could be fixed. 'cp' can already be told to preserve the metadata it knows about. 'tar' is a lost cause because you'd probably have to try and change the file format which wouldn't go over very well.
I'll read the white paper on reiserfs you linked. Maybe it'll end up providing some of the stuff I want.
Wow, that's a pretty good idea. Maybe somebody could code up a simple hack with your idea and somebody elses mention of XFS. Use XFS to store filetypes and possibly custom application handlers for files. And then a little "open" script which uses various information to find an application which can handle it. If you have a filetype already for the file, use it. If not, run 'file -i' to try and determine one. If that also fails, try to go by the extension. If that fails, error or open the file in a hex editor :-)
Under BeOS it was a library call, but a lot of things in *nix land are small programs instead of libraries. I wonder if anybody has already hacked something similar up?
The extended attributes would be a good place to put some stuff. Like filetypes, for example. By default BeOS didn't index those, and there isn't much need to. Due to the way the indexes were implemented, it would have been horribly slow anyway. So XFS might work well for that, or custom icons, or custom application bindings. There are quite a few things which are handy to keep track of about a file which are independant of it's contents or format.
But without the indexes, the attributes aren't useful for search-oriented actions. In my case, I really abuse the ability to search in my jukebox software. But since both MP3 and Ogg Vorbis include ways to store metadata in the stream itself, XFS doesn't add much benefit.
in-file metadata is fine for some purposes. If you want to keep your metadata intact as you moves the files around from system to system, it works well for that purpose. And if you just want your player to be able to pretty print the song information, it's fine.
But what about when I want to search the metadata in all of my songs? I've got something like 10GB of Ogg's. A majority of my music collection. Should the player search every file every time I do a query? No, that's ridiculous of course. Should I have the player scan every single song when it starts up and cache the infomation? Maybe if you don't mind reaaaly slow startup times. No, the place to keep that much information if you want to search it is in a database. And that's what BeOS did, in a nice simple standardized API. Oh, and did I mention that the queries can be live under BeOS? So if files are added or deleted which match an active query my application gets informed? There isn't really any way to replicate that with just ID3 tags without either polling (expensive) or kernel mods (which have their own development headaches.)
I too am at a loss to describe any existing problem which BeOS solves.
How about decent file typing? That's one thing BeOS did well, using MIME as the native file typing mechanism. MacOS had pretty good file types, but Apple seems to be discouraging it's use in favor of the lowest common denominator: file extensions. Which are frankly, crap.
Linux is probably at the bottom of the heap here. Both Gnome and KDE are starting to maintain their own databases of this stuff, which is pointless because this should be a common service OS-wide. An application should be able to ask the OS which application should be called to handle text/html for example. But there isn't any standard way to do that on Linux. As a result, different applications do different things when I click on a link. I want a Konq window to open, but there isn't any way for me to tell Evolution that. It insists on opening a Mozilla window.
I'm sure eventually this will get solved on Linux, but BeOS was handling this problem quite well five years ago. It isn't rocket science, in fact it's pretty simple.
Another example is file metadata. BeOS allowed you to add arbitrary name/value attributes to files. What's more, you could have the filesystem index them to allow you to do quick searches on them. Plus the Tracker allowed you to specify what attributes you wanted to have displayed in folder windows. You didn't have to look at the file name and size if you didn't want to. You could view only custom metadata.
This works great for audio files. The developers standarized on a set of attributes which all the major MP3 applications use. So all of my MP3 (well, Ogg actually) files have the artist, album, track, etc saved as metadata. The Tracker can be told to only display those attributes, if you want. Plus the OS can search on them. I've got a ripper thats adds the attributes when I rip a CD. I've got a file viewer, the Tracker, which lets me sift thru my collection looking at the relevant metadata. And I've got a player which lets me add file, folders, and arbitrary metadata queries to playlists.
Unfortunately, having my jukebox based on a dead OS is getting to be a drag for other reasons. So, I'll probably try to move the whole thing to Linux, but it'll be painful. I'll have to install my own database to handle the metadata. There's no standard schema so the few MP3 apps which do use databases won't interoperate. Not to mention that having the actual files and metadata completely disconnected is an extremely fragile solution. If you move a file using the normal techniques, then the metadata is out of sync and you have to fix it somehow. So I do what? Write my own interface for providing simple file manipulations so that I can keep the metadata in sync? That's not really practical either. In the end, I'll probably spend a lot of time implementing a solution that will work half as well.
Not that BeOS was perfect, far from it. Shall I discuss the pain of porting network software to an OS where sockets are not file descriptors? But it did have some really nice features which I have yet to find in any other OS.
Man, do I feel dumb. I don't even remember there being a Star Trek movie out over Christmas. Weird. They apparently only marketed it in media I don't pay attention to. Or maybe it's just the fact that there have been so many Star Trek movies that it just wasn't possible for my subconcious to register "Nemesis" as having an existence of it's own. Kind of like James Bond movies. My brain doesn't seem to be able to register the existence of new episodes of that series either. I'm just too damn old to waste brain cells trying to keep track of a dozen different Bond or ST flicks.
But I couldn't help but be a little put off by Prince's disrespect 4 the English languange as a means of xpression. I think I know why he hasn't released an album lately. He's been too busy hanging out in chat rooms.
he press release *seemed* to indicate that only the Athlon64 (single-processer desktop version) would be delayed, and perhaps not the Opteron (multi-CPU server version). However, it wasn't entirely clear.
So when the posted article said in the second paragraph:
Opteron, in keeping with the company's original launch date, is set to officially debut on April 22 in New York City.
That wasn't clear enough for you? Only the desktop and mobile versions are being delayed. Which makes sense. The market for a 64-bit laptop right now is pretty slim. But I think AMD will probably make the April release date. Opteron servers are actually shipping now in limited quantities to beta evaluators. And I actually touched a Linux-running, working, Opteron server at a conference last November. These things are a long way from being vapor. I'm betting that AMD just wants to be super careful since the server market is not very tolerant of crappy hardware.
I've been told that it'll be about a 20% hit to access the memory on the wrong processor. I haven't actually seen any benchmarks or anything, but that's what a guy in the AMD booth at Supercomputing '02 said.
Then watch as every e-mail from a windows user comes encrypted with a Palladium-approved e-mail app required for decryption.
This simply won't happen. Even Microsoft is not dumb enough to force people to send their email in a format which can't be read by the entire existing base of Windows users.
Or watch as any media file you find/download/buy/rip on a Windows PC gets encrypted and locked to that specific PC in hardware.
Watch as I don't buy anything using a Windows PC. Just like today. Some online content is only available in Windows Media Format. I don't listen or view it.
Or watch as web sites demand to check that you're running a Palladium-enabled system before you can enter.
Watch as I don't do business with that company. Hell, there's nothing new here. There are online companies I don't do business with today for the single reason that their web page doesn't work in Konq. Build an IE only web page? I won't use it. Besides, didn't you read the article? Linux users will probably be able to make use of TCPA based security for online transactions before Microsoft Windows users.
good to see IBM on-board. They've already written GPL drivers for Linux, and are showing massive support from the very beginning -- something you rarely see with *any* new specification or proposed standards. Any Linux user should be glad IBM is on-board as well.
Damn right. I assume you saw the articles earlier this week that IBM is claiming I think $1.5 billion in Linux based revenue, and HP is claiming $2.0 billion? Linux Brings In Big Bucks That kind of money can support some pretty serious development. It's not hard to imagine that Linux will end up with the premier set of software tools which does useful things with TCPA. Sure, maybe RedHat isn't bringing in the revenue they might like, but it sounds like free software as a whole is doing pretty damn well.
Of course, they don't mention that it's more than likely that in the near future, a version of Windows will take advantage of it
And so what? If you don't like the features Microsoft(tm) puts in their operating system, don't run Windows!. It's just that easy. You don't have to wait for TCPA for Microsoft(tm) to build objectionable stuff into their OS. Their Media Player already has DRM build into it. Don't like it? Don't run it. As Nancy Reagan liked to say, "Just Say No!"
My question to you is: what use, then, does TCPA serve?
Microsoft(tm) wants to position Windows as the premier content viewing platform for digital media. One way of doing this is to get the media companies to "trust" Windows. Specifically, the media cartel want to be able to have some certainty that the end user hasn't modified the operating system from it's original state. Sure, Microsoft can include software checks but these are trivially circumvented.
Enter TCPA. The BIOS acts as a "root of trust" (their term) which can be used to verify that the operating system has not been modified by the user. The TCPA BIOS will be audited, manufactured by trustworthy companies, and not easily modified by end users. The BIOS records the hash of the bootloader, which records the hash of the operating system loader, etc. etc. The goal being to force people who want to circumvent the operating system security to use hardware cracks. Presumably that's the only way to get the media cartel to "trust" your platform. And if all the online media is only available under Windows, that's big cha-ching for Microsoft going forward. Not to mention making things like product activation much more resiliant. Isn't that reason enough?
why does Microsoft need TCPA if Microsoft is not planning to introduce features into Windows which are only available via MS-approved boot loaders? This would be an anti-competitive move, yes,
Microsoft will introduce features which are only available thru a certified bootloader. That's the whole point! You can't very well pretend that the operating system is running in a known secure state if it's running inside of VMware, now can you? But like I said, at worst that will just mean that you'll have to the Microsoft bootloader to get to LILO. A pain perhaps, but not something that is likely to be seen as anti-competetive.
Instead of getting our panties up in a knot, we should be trying to figure out how to make use of the new features TCPA will provide. Like how about a secure partition which can't be mounted/decrypted if you're computer is booted from a floppy? Or how about a distribution like Debian using this to ensure that package submissions only come from fully-patched up-to-date systems? Or for that matter, allowing clients downloading updates to verify that the server hasn't been rooted! Now that would be cool.
Sounds like a bad "In Soviet Russia..." joke.
:-)
I'll take a stab at it:
In Soviet Russia, music listens to you
Actually, one of the better ones I think
The TCPA standard talks a lot about the "Owner" of the system, and how the "Owner" can initialize a new system so that it will begin generating keys and such using a password set up during the "ownership" process (See Section 2.6 of the Standard). My question is: who would the "Owner" of a system normally be in plain english? The actual end-user (or their administrator)? Or would the TPM get "owned" by the hardware vendor (Dell, HP, etc.) Or the OS vendor? Or the motherboard manufacturer?
Second, will it be possible to completely reset the TPM to a non-owned state to allow used hardware to be sold "as new"? Or would the hardware refuse to allow a new owner?
If I understood the prior articles correctly, TCPA should provide
I'm amazed at how common this meme has become despite the fact that it is completely false. TCPA in no way dicates what code can run on the machine. The "security" it offers works in pretty much the reverse fashion. The TCPA BIOS hashes the bootloader and saves that hash in a secure place. That allows the bootloader to verify that it really did run first. The bootloader can then hash some portion of the OS, and then load and execute it. The OS can then verify that the boot process really was TCPA-BIOS->Correct bootloader->Unmodified OS. And more importantly, the OS can have the BIOS give it a cryptographic "proof" of this fact to hand to other programs or web sites.
What does this mean for Linux? Probably nothing. Linux could make use of this functionality, but my guess is it probably won't. The fact is that unless your code actually bothers to check the TCPA state of the machine, it just doesn't matter.
On the other hand, Palladium might make some things a little trickier. Since the bootloader is part of the TCPA chain of trust, it's highly unlikely that Palladium will be able to enter it's "secure" mode if you are using LILO or grub. So if you are somebody who actually dual-boots you will probably have to have an official Microsoft bootloader on
Could Microsoft abuse this to try to prevent users from dual booting? Sure. But they could easily prevent people from dual booting today if they wanted to. It's just that it would be such a blatantly anti-competetive move that even Microsoft would have a hard time pulling it off. They could refuse to boot thru LILO. They could complain and offer to "fix" any non-FAT or NTFS partitions at every boot. They could use browser version strings to control access to updates on their web site and bring DMCA charges against browsers which circumvent that by pretending to be IE. TCPA doesn't really make it easier to Microsoft to screw with people who dual boot. It's already trivial today!
It's probably too late for anyone to read this, but what the hell. Last night I found what I'm 90% certain is a professional pirated CD in my collection. It's a disc of Christmas carols that my wife bought at her dad's church last year. It looks professional, being silkscreened and being a pressed CD not burned. But it doesn't have a case, just a paper sleeve. What really tipped my off is that when I asked my ripper to identify it freedb.org, I got back a different title!. Identical tracks. Identical lengths. Identical songs. But a totally different (and more generic) title. When I looked more closely at the CD, I realized that it had no indication of copyright at all! "What the hell???", I thought.
I may have to try and buy the legit version of the CD and show 'em both to my father-in-law next time I see him. I can't decide if I'm appaled or amused by the thought of some guy making thousands of pirated CDs and selling them to churches to use as a fund-raising item. I guess it's typical. You're average church-goer is the kind of person who would wander from house to house publicly performing copyrighted works without paying royalties anyway.
And those are from charities, time-warner cable (since we already have a "business relationship" with them)
Just tell time-warner to put you on their do not call list, and that if they call again you're going to cancel your service and get DirectTV or something. I used to get calls from both Qwest (my phone company) and MBNA (credit card), but neither one has called for quite some time after I told them that they would lose me as a customer if they called again. FWIW, I'm also on Colorado's do not call list. I think I've gotten maybe one commercial telemarketer call since the list went into effect about six months ago. I'm actually hoping one will call so I can sue 'em. I still get the occasional charity and politial call (around election time), but not very many.
PD's, FD's, Hospitals, etc. are all considered to be zones absolutely off limits to any such interference this would cause
So it's illegal to use 802.11b, a 2.4GHz cordless phone, or a microwave oven in the same region as a fire department, a police department, or a hospital? Quite frankly, I think you're wrong and yours is the first such claim I've heard regarding the use of unlicensed spectrum. Please provide a reference, as it appears you believe that the FCC was quite irresponsible in allowing retailers to sell such dangerous devices to the general public.