And it only took about 6.5 hours between the
posting of this story and
the posting of a new story
Consumer Electronics Companies Plan Common DRM Standard in which Sony is once again an evil corporation hell-bent on ensuring that every media device sold is sold with inbuilt DRM.
I already addressed that in another reply,
namely link an inode (specified by number)
into the filesystem (specified by a pathname).
I'm just suggesting that some extra filesystem
operations would help to alleviate the dangers
posed by privileged processes accessing the filesystem (e.g. for maintenance purposes).
The solution, not reusing inode numbers, would cause filesystems to have finite lifetimes.
Not necessarily. Assume the system guarantees that a given inode number refers to only the same file contents (and inode contents too). How long does the system need to make this guarantee? Forever? Across reboots?
The system needs to guarantee only for the lifetime of the process which is told that inode number. This is easily implemented with a reference count, the same way we reference-count files already (but not the same reference count obviously, one's required to know when to delete a file).
And I presume you're the one to volunteer to develop and maintain compatibility for the next decade (or two) for binary-only or closed source programs; as well as to update and debug all current source code code to use new semantics etc.
Give me a break. The question was "what's wrong with Unix and how would you fix it?". I'm commenting on what I would do differently if I were redesigning Unix. Obviously if Unix is redesigned, it would not be unix anymore. That's not to say that unix semantics could not be emulated by a successor operating system.
Anyway, your requirement for backwards compatibility of binary applications is a straw man. I talk not of Unix, but of the system which
will succeed it. Just yesterday I did a bit of googling on tail-merging capabilities in filesystems. And I came upon this little story,
which I will use to illustrate my point:
Some dude wrote patches to the EXT2 filesystem to support tail-merging of files
Linus refused to add it to the kernel, even though the patch provided backward compatibility for filesystems written without the tail-merging code. Why?
Best I let linus explain it here; this is from an article in LWN in 2001...
When Mr. Phillips mentioned plans to provide tail-block fragmentation for ext2, Linus jumped in and asked that it not be done. He has no objection to the technique, it's just that he thinks a whole new filesystem should be created. Rather than just graft on tail-block fragmentation, a complete rethink should be done to create a better, extent-based filesystem with a vary large block size. And it should not be called "ext2."
In another posting he explained his reasoning in more detail; it is an interesting look at his philosophy for the evolution of the Linux code. Essentially, creating a new code base makes it easier to eventually get rid of the old one, leading to better long-term maintainability. A transition to a completely new filesystem can be done on the user's own time, and can happen relatively smoothly.
In comparison, if you have "new features in X, which also handles the old cases of X" situation, you not only bind yourself to backwards compatibility, but you also cause yourself to be unable to ever phase out the old code. Which means that eventually the whole system is a piece of crap, full of old garbage that nobody needs to use, but that is part of the new stuff that everybody _does_ use.
BTW I think you misunderstand what an inode is. How would you propose renaming an inode n(or do you mean renumber)? Why would you want to do so? Do you also want to have a creat() that allows you to specify the inode number? Also, what do you propose happen if an inode currently in use is deleted?
I know exactly what an inode is. "rename an inode" might be better put as "link an inode number to a node in the filesystem". Sure there's fstat and fchmod, but they require that the file be opened
first. Opening a file may be a problem in itself - say it's a device, maybe a tty - the RTS and DTR lines would go up.
I'd like to see opening a file by its inode number. Then a process could first stat() the file and thus learn its inode number and then open it by that number, and the OS would guarantee that the file opened is the same file stated.
I'm unsure exactly what you mean by an attacker switching the filesystem around
You're unaware of all the well-known security holes which are caused by unsafe filesystem operations?
All I'm saying is that providing an interface to do some filesystem operations at the inode level may prevent attackers from exploiting race conditions which they currently may do by any of several means, including renaming files, switching intermediate directory names, adding (or removing) symlinks, and so on.
Besides, termcap is obsolete, everyone (including ncurses) actually uses terminfo these days
My bad. I should have said termcap and
terminfo.
Maybe it's not so bad now, but a few years ago half of the utilities used termcap and half
terminfo. Looked like the two libraries were
battling for mindshare.
To fix unix, it is important to start from the bottom up. Ignoring kernel internals, which are
the choice of the kernel developer, the layer we need to fix first is the system call interface.
For example:
Rename creat to create, as it should always have been
64-bit time_t
localtime to return the year number, not year-1900
Decide whether we like curses or termcap, and get rid of the other one
Add inode-level operations, i.e. open an inode, rather than a path. Add atomic filesystem operations. Rename an inode. Delete an inode. Path-level operations permit race conditions whereby an attacker switches the filesystem around in between a privileged process examining the filesystem and making a change to the filesystem.
I won't repeat the comments which have already
been posted here which say that spammers aren't
diligent in updating their email address lists.
The point I would like to mention though is that
spammers sell address lists, particularly to new
spammers, and they merge their existing address
lists with newly purchased lists. That means that
old email addresses are continually re-targeted
by new spammers.
I don't believe the MPAA are currently prosecuting plagiarism, so I'm safe on that!
Anyway, it's a cultural thing, like "In Soviet
Russia, new media format buys you!". See Larry Lessig's talk in Finland for more information (can't remember url sorry).
Australia has had traffic lights which vary their
timing based on traffic conditions for many
years (PDP-11s in the switch boxes beside the lights).
It's very unusual for Australian lights to operate on strict timing intervals when traffic flow data is available. It happens late at night... when there is no traffic whatsoever, some lights will cycle through a defined sequence at the same rate... but other lights will stay green continually on the more major road until some traffic arrives at the less major road.
With the release of the USL/UCB settlement today, The SCO Group has moved swiftly to maximise their revenue opportunities. With their court cases in tatters on several fronts, the disclosure of the formerly secret settlement document has prompted a quick realignment of focus in The SCO Group headquarters.
Their new strategy is simple. "We own all your code" said Chris Sontag. "Pay us all your money".
Analcyst Laura Didiot of The Yankee Group recommended that any companies NOT intending to do business with The SCO Group should immediately discuss this position with their lawyers.
Open Source Advocate Eric S. Raymond was quoted as responding "Haw Haw! We don't condone that kind of behaviour at all. No, not at all."
Richard M Stallman, in a surprising departure from convention, declined to call the new strategy "GNU/Extortion". He described the process of paying money to sleazy litigious bastards as "not aligned with the ideals of a free society".
Linus Torvalds, inventor of the Linux Operating System at the core of The SCO Group's wild claims, declined to make his usual witty one-line comment. "They are supplying the punch line this time", he said.
I can't access
homework I created on my TRS-80 Model 4 just 20 years
ago even though I have the single-sided 5 1/4-inch
disks in my closet.
You're just not trying hard enough.
I did mine... see www.nick-andrew.net and there's all of it - it's online, available to the world, been copied to www.trs-80.com, backed up on two continents as well as CDR.
Although I had quite a hard time retrieving the data from the 5.25 inch disks, the work's done now and the original 5.25" disks have been destroyed and I now have multiple copies of it all on fresh media.
I realised a few years ago that the only sane way to protect my data was to have it all online all the time.
Much the same here. I keep it all online, on LVM over RAID-1, and regular incremental backups to CDR.
The trick with the CDR backups is that, though they are incremental, whenever there's room left on the media after backing up new and modified files, unmodified files get backed up again. Thus, over time, I build up multiple backups of everything.
There might be an issue 50 years from now when I want to get back some file I had (and deleted) 50 years ago, and its CDR backup has degraded. But that situation can only occur for a deleted file... which, according to my "all online all the time" policy, is something I won't ever need
back.
As for my previous digital camera pictures though, they'll stay online, on the disks, and they'll be backed up repeatedly through the ages, so if I ever suffer a disk catastrophe they're recoverable from the backups.
When I jumped through the Joker hoops to tell them that I wanted to transfer my domain name, they opened a "transfer window". I was shocked when they said that, during the transfer window, _any_ registrar could grab my domain.
I suspect that the people at Joker were trying to intimidate (or FUD) you into staying with them instead of transferring to another registrar.
I wasn't intimidated, but I was worried about the
possibility of somebody else issuing a transfer request during the "transfer window".
The protocol specifies that the gaining registrar has to get confirmation of the identity of the domain owner making the request before initiating the transfer.
That's the safeguard in the protocol. The gaining registrar must verify that the registrant approves the transfer... via any of a variety of means, not only email but also a signed letter. But it strikes me as bad design.
That's basically "putting the authorisation onto
the client", in this case the client being the gaining registrar. It's a basic design flaw and the kind of thing that Bruce Schneier points out from time to time. For example, airline pilots wouldn't let
somebody into the cockpit on the strength of them
saying "it's okay, I'm authorised to go in". They'd ask to see a badge, and verify the badge's
authenticity themselves.
The justification for this protocol change is said to be to protect registrants from unscrupulous current registrars. But as I said earlier, the need for protection against many unwanted transfers is much stronger than the need to ensure that the single, wanted transfer goes through. Within the new protocol, losing registrars still have the ability to hold back transfers by, say, automatically locking all domains and making it difficult for the customer to unlock a domain. Somebody said that ICANN didn't have the balls to punish registrars who were gaming the old protocol - why should I believe that ICANN will be any less toothless under the new protocol?
There are two main problems with the new protocol.
First, the current registrar must approve
a transfer of domain without obtaining the
registrant's approval. This is contrary to
common sense. If the purpose is to stop
registrars from unreasonably holding domain
names, then the appropriate response is to
require the current registrar to approve a
transfer request when the registrant has
approved it. If the registrant approves, and
the current registrar rejects, that's an
appropriate cause for complaint.
After all, isn't it more important to protect
existing domains from unscrupulous transfers,
than to prevent rogue registrars from accepting
legitimate transfers? I may have one legitimate
reason to move my domain from one registrar to
another but there are a large number of scammers
who would gladly capture my domain for fraud or
other purposes.
It's a bit ridiculous that every registrar
should be forced to implement a locking
function, and every domain holder should be
forced to lock every domain, all at once,
in order to protect themselves from fraud.
Secondly, the "unlock" action required prior
to a legitimate transfer opens a window
of time in which a domain can be stolen - in
programming parlance, a race condition. It's
a problem with the protocol.
Just the other day I transferred several domains
from Joker to GoDaddy. Joker isn't very easy to
deal with, and GoDaddy is cheaper, so I decided
to move the Joker ones to GoDaddy.
When I jumped through the Joker hoops to tell
them that I wanted to transfer my domain name,
they opened a "transfer window". I was shocked
when they said that, during the transfer window,
_any_ registrar could grab my domain. Not just
GoDaddy. Not just me. Any user of any other registrar
could have issued a transfer request for my
domain name, through their registrar to Joker,
and Joker would have accepted it, if the request
arrived before my legitimate request from GoDaddy.
Indeed, any user of GoDaddy could have done the
same thing, because there's nothing in the request itself to say that it was me who
instigated that request.
What happened to the good old days when a request
for a transfer resulted in an email from my registrar to me, asking for my approval. If I approve, the transfer will go through. If I'm not there or indisposed, overseas or not reading my email, then the transfer will not happen.
From what I understand (I'm not an expert but I've read a little), the people who these scammers appeal to often aren't the people who are simply greedy. They're the people who've been told that they need a $100,000 payment on their home within a month or they and their kids will be kicked out of the home that's been in their family for generations
Let's see then. Here are some victims found by a Google search (top links chosen)
awprofessional.com wrote:
In July 2001, the Times of London reported that a former mayor of Northampton fell for the 419 scam, and ended up in Johannesburg, South Africa with a gun to his head.. Not certain, but more likely to be greed than desperation.
In the same URL, And in 1999, a Romanian businessman, Danut Mircea Tetrescu, was kidnapped and held for a half-million dollar ransom.. Hmm, "Romanian businessman". More likely greed?
In the same URL we also have Kjetil Moe, a Norwegian millionaire who had fallen for the 419 scam. Definitely greed.
El Reg writes of a woman who stole $2.1m from the law firm of which she was an employee (a bookkeeper). The Reg analyses it for us: greed and stupidity in equal measure.
Wired wrote 2+ years ago of two losses of $78k and $74k, but no actual explanation of the motives of the victims.
This dude writes that he was taken in out of folly.
From earlier sections you might have picked up the impression that only seniors are deceived by offers of instant wealth. Nothing could be further from the truth. While it is true that seniors are targeted for sweepstakes offers the mechanics of telemarketing and investment fraud are simply enhanced and modified for attacking various targets of opportunity.
This particular scam targets middle class, middle age, business and professional men who would never be as easily deceived by a lottery scam. Estimates put the losses from these "Nigerian Advance Fee" operations at over $1 million "every single day" in the U.S. alone.
Can I ask WHY you aren't using a Corporate Key for your copy of XP?
Because you can't tell what Windows is ever
going to do with that key. You might find that
when you connect to the net, your OS phones home
to Microsoft. Or maybe an application reports your key to its owner.
Or perhaps your key is embedded in some document
which you create. Any of those things can constitute evidence that such-and-such is using a stolen key. And that might be bad for you in the future, even if you do have legit copies.
Basically you don't know what your software might do. And that's a consequence of
using proprietary software which requires registration.
Or you could decide that you care about such
things, and choose Free (as in Freedom) software
instead.
Slashdot Mirror
And it only took about 6.5 hours between the posting of this story and the posting of a new story Consumer Electronics Companies Plan Common DRM Standard in which Sony is once again an evil corporation hell-bent on ensuring that every media device sold is sold with inbuilt DRM.
... Anybody but Verisign!
I'm just suggesting that some extra filesystem operations would help to alleviate the dangers posed by privileged processes accessing the filesystem (e.g. for maintenance purposes).
Not necessarily. Assume the system guarantees that a given inode number refers to only the same file contents (and inode contents too). How long does the system need to make this guarantee? Forever? Across reboots?
The system needs to guarantee only for the lifetime of the process which is told that inode number. This is easily implemented with a reference count, the same way we reference-count files already (but not the same reference count obviously, one's required to know when to delete a file).
Give me a break. The question was "what's wrong with Unix and how would you fix it?". I'm commenting on what I would do differently if I were redesigning Unix. Obviously if Unix is redesigned, it would not be unix anymore. That's not to say that unix semantics could not be emulated by a successor operating system.
Anyway, your requirement for backwards compatibility of binary applications is a straw man. I talk not of Unix, but of the system which will succeed it. Just yesterday I did a bit of googling on tail-merging capabilities in filesystems. And I came upon this little story, which I will use to illustrate my point:
Best I let linus explain it here; this is from an article in LWN in 2001...
BTW I think you misunderstand what an inode is. How would you propose renaming an inode n(or do you mean renumber)? Why would you want to do so? Do you also want to have a creat() that allows you to specify the inode number? Also, what do you propose happen if an inode currently in use is deleted?
I know exactly what an inode is. "rename an inode" might be better put as "link an inode number to a node in the filesystem". Sure there's fstat and fchmod, but they require that the file be opened first. Opening a file may be a problem in itself - say it's a device, maybe a tty - the RTS and DTR lines would go up.
I'd like to see opening a file by its inode number. Then a process could first stat() the file and thus learn its inode number and then open it by that number, and the OS would guarantee that the file opened is the same file stated.
I'm unsure exactly what you mean by an attacker switching the filesystem around
You're unaware of all the well-known security holes which are caused by unsafe filesystem operations?
All I'm saying is that providing an interface to do some filesystem operations at the inode level may prevent attackers from exploiting race conditions which they currently may do by any of several means, including renaming files, switching intermediate directory names, adding (or removing) symlinks, and so on.
My bad. I should have said termcap and terminfo.
Maybe it's not so bad now, but a few years ago half of the utilities used termcap and half terminfo. Looked like the two libraries were battling for mindshare.
For example:
I'll bet that Encyclopaedia Britannica doesn't even have an entry for Patrick Volkerding.
Capiche?
I'll bet they don't even have an entry for Patrick Volkerding!
it's a joke, laugh ...
If it's so correct then tell me this: Did they rename creat() to create()??
The point I would like to mention though is that spammers sell address lists, particularly to new spammers, and they merge their existing address lists with newly purchased lists. That means that old email addresses are continually re-targeted by new spammers.
Anyway, it's a cultural thing, like "In Soviet Russia, new media format buys you!". See Larry Lessig's talk in Finland for more information (can't remember url sorry).
Guess I gotta go buy that White Album again now.
No way they can say that Earth shot first.
It's very unusual for Australian lights to operate on strict timing intervals when traffic flow data is available. It happens late at night ... when there is no traffic whatsoever, some lights will cycle through a defined sequence at the same rate ... but other lights will stay green continually on the more major road until some traffic arrives at the less major road.
Their new strategy is simple. "We own all your code" said Chris Sontag. "Pay us all your money".
Analcyst Laura Didiot of The Yankee Group recommended that any companies NOT intending to do business with The SCO Group should immediately discuss this position with their lawyers.
Open Source Advocate Eric S. Raymond was quoted as responding "Haw Haw! We don't condone that kind of behaviour at all. No, not at all."
Richard M Stallman, in a surprising departure from convention, declined to call the new strategy "GNU/Extortion". He described the process of paying money to sleazy litigious bastards as "not aligned with the ideals of a free society".
Linus Torvalds, inventor of the Linux Operating System at the core of The SCO Group's wild claims, declined to make his usual witty one-line comment. "They are supplying the punch line this time", he said.
You're just not trying hard enough. I did mine ... see www.nick-andrew.net and there's all of it - it's online, available to the world, been copied to www.trs-80.com, backed up on two continents as well as CDR.
Although I had quite a hard time retrieving the data from the 5.25 inch disks, the work's done now and the original 5.25" disks have been destroyed and I now have multiple copies of it all on fresh media.
Much the same here. I keep it all online, on LVM over RAID-1, and regular incremental backups to CDR.
The trick with the CDR backups is that, though they are incremental, whenever there's room left on the media after backing up new and modified files, unmodified files get backed up again. Thus, over time, I build up multiple backups of everything.
There might be an issue 50 years from now when I want to get back some file I had (and deleted) 50 years ago, and its CDR backup has degraded. But that situation can only occur for a deleted file ... which, according to my "all online all the time" policy, is something I won't ever need
back.
As for my previous digital camera pictures though, they'll stay online, on the disks, and they'll be backed up repeatedly through the ages, so if I ever suffer a disk catastrophe they're recoverable from the backups.
I suspect that the people at Joker were trying to intimidate (or FUD) you into staying with them instead of transferring to another registrar.
I wasn't intimidated, but I was worried about the possibility of somebody else issuing a transfer request during the "transfer window".
The protocol specifies that the gaining registrar has to get confirmation of the identity of the domain owner making the request before initiating the transfer.
That's the safeguard in the protocol. The gaining registrar must verify that the registrant approves the transfer ... via any of a variety of means, not only email but also a signed letter. But it strikes me as bad design.
That's basically "putting the authorisation onto the client", in this case the client being the gaining registrar. It's a basic design flaw and the kind of thing that Bruce Schneier points out from time to time. For example, airline pilots wouldn't let somebody into the cockpit on the strength of them saying "it's okay, I'm authorised to go in". They'd ask to see a badge, and verify the badge's authenticity themselves.
The justification for this protocol change is said to be to protect registrants from unscrupulous current registrars. But as I said earlier, the need for protection against many unwanted transfers is much stronger than the need to ensure that the single, wanted transfer goes through. Within the new protocol, losing registrars still have the ability to hold back transfers by, say, automatically locking all domains and making it difficult for the customer to unlock a domain. Somebody said that ICANN didn't have the balls to punish registrars who were gaming the old protocol - why should I believe that ICANN will be any less toothless under the new protocol?
First, the current registrar must approve a transfer of domain without obtaining the registrant's approval. This is contrary to common sense. If the purpose is to stop registrars from unreasonably holding domain names, then the appropriate response is to require the current registrar to approve a transfer request when the registrant has approved it. If the registrant approves, and the current registrar rejects, that's an appropriate cause for complaint.
After all, isn't it more important to protect existing domains from unscrupulous transfers, than to prevent rogue registrars from accepting legitimate transfers? I may have one legitimate reason to move my domain from one registrar to another but there are a large number of scammers who would gladly capture my domain for fraud or other purposes.
It's a bit ridiculous that every registrar should be forced to implement a locking function, and every domain holder should be forced to lock every domain, all at once, in order to protect themselves from fraud.
Secondly, the "unlock" action required prior to a legitimate transfer opens a window of time in which a domain can be stolen - in programming parlance, a race condition. It's a problem with the protocol.
Just the other day I transferred several domains from Joker to GoDaddy. Joker isn't very easy to deal with, and GoDaddy is cheaper, so I decided to move the Joker ones to GoDaddy.
When I jumped through the Joker hoops to tell them that I wanted to transfer my domain name, they opened a "transfer window". I was shocked when they said that, during the transfer window, _any_ registrar could grab my domain. Not just GoDaddy. Not just me. Any user of any other registrar could have issued a transfer request for my domain name, through their registrar to Joker, and Joker would have accepted it, if the request arrived before my legitimate request from GoDaddy. Indeed, any user of GoDaddy could have done the same thing, because there's nothing in the request itself to say that it was me who instigated that request.
What happened to the good old days when a request for a transfer resulted in an email from my registrar to me, asking for my approval. If I approve, the transfer will go through. If I'm not there or indisposed, overseas or not reading my email, then the transfer will not happen.
Let's see then. Here are some victims found by a Google search (top links chosen)
And they called us vigilantes ...!
You could use Linux. I'm sure I could do all that stuff for free.
Because you can't tell what Windows is ever going to do with that key. You might find that when you connect to the net, your OS phones home to Microsoft. Or maybe an application reports your key to its owner. Or perhaps your key is embedded in some document which you create. Any of those things can constitute evidence that such-and-such is using a stolen key. And that might be bad for you in the future, even if you do have legit copies.
Basically you don't know what your software might do. And that's a consequence of using proprietary software which requires registration.
Or you could decide that you care about such things, and choose Free (as in Freedom) software instead.