/etc/mtab has been obsolete for years, we just have to keep using it because there is no reasonable replacement. What we need is/proc/mounts to be improved enough to serve as replacement, or possibly a new/proc/mtab (and leave/proc/mounts unchanged for compatibility). What is most important to get added is the few extra fields needed by userspace, those should be set through the mount call and readable like all other mount options. Of course the userspace mount utility needs to be rewritten as well.
I have written a few lines of the Linux kernel, and since SCO have publicly stated, that they do not accept the GPL, I see no problem in revoking their license. By SCO logic (since UNIX code is in Linux) that also mean their UNIX license has been revoked.
Considering I am listed on the linux counter and have not used linux for about 5-6 years now
If you are still on that list, you must have renewed your registration at least twice in the last few years. Why did you do that, when you had not been using Linux for more than three years?
either the investors are idiots or we're missing something.
So what would be interesting to know is, what are the investors thinking? When the stock goes up, it must mean some people are willing to pay those prices. Would some of those buyers step forward and tell us why they bought? Do they think SCO possess anything of value, or do they just hope the stock will go a little higher before dropping?
Oooh, you play with fire man! You shouldn't be assigning ports 1025 unless root.
What are you trying to tell me? Of course I do my backup as root. And I must ensure nobody else starts listening on the port, thus it must be less than 1024. I know which protocols are being used on my computers, and 200 is not even assigned in/etc/protocols.
10^57 bytes, in what time, and how fast a computer should be?
It is a dynamic algorithm, so the time spent is not going to be much more than the time it takes to fill up the memory with partial results. In this particular case I guess the time usage would be about 10^60 clockcycles. The interesting question, which I will not try to answer is: Can the algorithm be parallelized?
Re:Can't wait for Novell Storage System on Linux
on
Linux File System Shootout
·
· Score: 2, Interesting
Copy on Write and directory quotas are stuff I'd really like to see in Linux filesystems. The combination of hardlinks and directory quotas is however very tricky, any pointers to implementations that made this work in the right way?
Like I said, who cares about NTFS or FAT performance?
FAT performs well as long as you just do sequential access to large files. But don't access too many files at the same time, because there are only eight entries in the fat_cache. If you run over this limit or do random access FAT is going to be the worlds slowest filesystem. And that is so bad it has really caused me trouble some times.
The reality is minix is faster, cleaner, simpler, and more flexible than FAT. Just take a look on the source minix 47KB, fat 131KB. And keep in mind that minix use a a fast tree structure to locate blocks while FAT use an extremely slow linked list.
It is, and there is. The game tree for chess, however, is simply so large that finding the optimal solution probably exceeds the computational power of the universe, or something like that.
With dynamic programming it can be solved in 10^57 bytes of memory. Possibly a lot less if you are clever.
a new client that connects to a peer that is almost finished with the stream
What I had in mind was live broadcast like on the radio. When you turn it on, you don't get it from the start of the programme, you get what is broadcast right now.
the broadcast is no longer live, but delayed considerably.
There will be a delay, but keeping it below 10 seconds shouldn't be a problem. Such a delay would be unacceptable for telephone over the internet, but it is surely acceptable for internet radio.
What about low-bandwidth nodes on the tree?
That is obviously a potential problem. Keeping the high bandwith nodes near the root and the low bandwith nodes near the leaves would somehow help. I don't know much about lossy compressions, but if the compression can be designed such, that conversion to lower bit rates can easilly be performed, we will more or less have solved the problem.
everyone would be downloading the same thing, thus diminishing its value.
Just means it cannot work like bit torrent. There are other ways to distribute data. What you need to do is utilize the fact, that everybody wants the same data at the same time. Build a tree structure of clients each repeating everything they receive to two or three other clients, possibly with some redundancy, such that leaves repeat to different locations in the tree. The tricky part will be to dynamically compute a least cost tree.
Or I could upgrade my internet connection to get the same amount of storage in other locations. In about three months the extra required capacity on the internet connection would have cost me as much as the harddisk. If I buy the harddisk now, in three months I will still have storage without having to keep paying. Besides, the harddisk is going to be more efficient and probably also more reliable.
it's pretty damn hard to spoof the very last Received: header of a message,
You are right, so rather than trying to spoof it, it is much simpler to make somebody elses computer acutally send the message. Some spammers find a misconfigured HTTP proxy which they try to abuse to establish a connection to an SMTP server. Now the new Received: header will point at the proxy, and the previous Received: headers will be forged. Sometimes spammers even try to find an SMTP server, that will relay mail from the proxy's IP. For example they sometimes use localhost:25 or look for an SMTP server with an IP in the same subnet. They even sometimes use the domain name of one of the abused computers in the HELO or the MAIL From commands.
Slashdot Mirror
When I need a serial console I still use my Olivetti PCS 286 from '91 running DOS.
/etc/mtab has been obsolete for years, we just have to keep using it because there is no reasonable replacement. What we need is /proc/mounts to be improved enough to serve as replacement, or possibly a new /proc/mtab (and leave /proc/mounts unchanged for compatibility). What is most important to get added is the few extra fields needed by userspace, those should be set through the mount call and readable like all other mount options. Of course the userspace mount utility needs to be rewritten as well.
I can tell you that Opera (on both Linux and XP) has no problems either.
Actually I have minor problems when using Opera. OTOH I have no problems when using Mozilla.
I have written a few lines of the Linux kernel, and since SCO have publicly stated, that they do not accept the GPL, I see no problem in revoking their license. By SCO logic (since UNIX code is in Linux) that also mean their UNIX license has been revoked.
once more ... google doesnt like IPs
/. that doesn't like your way of posting links.
Here is a working link.
Nope, it is just
Considering I am listed on the linux counter and have not used linux for about 5-6 years now
If you are still on that list, you must have renewed your registration at least twice in the last few years. Why did you do that, when you had not been using Linux for more than three years?
Other countries use period instead of a comma to deliminate thousands. It means 130,000.
Where I live we use dots as delimiter between thousands and a comma to indicate decimals. So we write numbers like: 1.057.612,75
either the investors are idiots or we're missing something.
So what would be interesting to know is, what are the investors thinking? When the stock goes up, it must mean some people are willing to pay those prices. Would some of those buyers step forward and tell us why they bought? Do they think SCO possess anything of value, or do they just hope the stock will go a little higher before dropping?
Oooh, you play with fire man! You shouldn't be assigning ports 1025 unless root.
/etc/protocols.
What are you trying to tell me? Of course I do my backup as root. And I must ensure nobody else starts listening on the port, thus it must be less than 1024. I know which protocols are being used on my computers, and 200 is not even assigned in
10^57 bytes, in what time, and how fast a computer should be?
It is a dynamic algorithm, so the time spent is not going to be much more than the time it takes to fill up the memory with partial results. In this particular case I guess the time usage would be about 10^60 clockcycles. The interesting question, which I will not try to answer is: Can the algorithm be parallelized?
Who the hell moderated the parent overrated? Moderators get serious and moderate the parent informative!
After calling Linux and the GPL a cancer
If SCO are right in any of their claims, closed source is a lot worse in that respect than any GPL code could ever be.
This is source.
Of course if you really want to browse the source you'd be using a different source navigator.
Copy on Write and directory quotas are stuff I'd really like to see in Linux filesystems. The combination of hardlinks and directory quotas is however very tricky, any pointers to implementations that made this work in the right way?
Like I said, who cares about NTFS or FAT performance?
FAT performs well as long as you just do sequential access to large files. But don't access too many files at the same time, because there are only eight entries in the fat_cache. If you run over this limit or do random access FAT is going to be the worlds slowest filesystem. And that is so bad it has really caused me trouble some times.
The reality is minix is faster, cleaner, simpler, and more flexible than FAT. Just take a look on the source minix 47KB, fat 131KB. And keep in mind that minix use a a fast tree structure to locate blocks while FAT use an extremely slow linked list.
When transfering lots of data between two computers nothing beats netcat. I use it for my backups:But for accessing the same
It is, and there is. The game tree for chess, however, is simply so large that finding the optimal solution probably exceeds the computational power of the universe, or something like that.
With dynamic programming it can be solved in 10^57 bytes of memory. Possibly a lot less if you are clever.
they'd raise their prices for registrars
Now that would be innovative, wouldn't it?
a new client that connects to a peer that is almost finished with the stream
What I had in mind was live broadcast like on the radio. When you turn it on, you don't get it from the start of the programme, you get what is broadcast right now.
the broadcast is no longer live, but delayed considerably.
There will be a delay, but keeping it below 10 seconds shouldn't be a problem. Such a delay would be unacceptable for telephone over the internet, but it is surely acceptable for internet radio.
What about low-bandwidth nodes on the tree?
That is obviously a potential problem. Keeping the high bandwith nodes near the root and the low bandwith nodes near the leaves would somehow help. I don't know much about lossy compressions, but if the compression can be designed such, that conversion to lower bit rates can easilly be performed, we will more or less have solved the problem.
And you thought Resident Evil was just a game?
Actually I have seen the movie, reminds me too much about "Night of the Living Dead" and "Deep Blue Sea".
It just came to my mind, that SCO might stand for Small Cock Operation, because as Linus told us: Their business was zero and it was shrinking.
Here are a few suggestions I have seen a few times (some of them here on
everyone would be downloading the same thing, thus diminishing its value.
Just means it cannot work like bit torrent. There are other ways to distribute data. What you need to do is utilize the fact, that everybody wants the same data at the same time. Build a tree structure of clients each repeating everything they receive to two or three other clients, possibly with some redundancy, such that leaves repeat to different locations in the tree. The tricky part will be to dynamically compute a least cost tree.
Or I could upgrade my internet connection to get the same amount of storage in other locations. In about three months the extra required capacity on the internet connection would have cost me as much as the harddisk. If I buy the harddisk now, in three months I will still have storage without having to keep paying. Besides, the harddisk is going to be more efficient and probably also more reliable.
it's pretty damn hard to spoof the very last Received: header of a message,
You are right, so rather than trying to spoof it, it is much simpler to make somebody elses computer acutally send the message. Some spammers find a misconfigured HTTP proxy which they try to abuse to establish a connection to an SMTP server. Now the new Received: header will point at the proxy, and the previous Received: headers will be forged. Sometimes spammers even try to find an SMTP server, that will relay mail from the proxy's IP. For example they sometimes use localhost:25 or look for an SMTP server with an IP in the same subnet. They even sometimes use the domain name of one of the abused computers in the HELO or the MAIL From commands.