It's not as hard as you think. NASA's 2006 budget is $16 billion dollars. That money is already in the congressional budget. Now NASA can use their next 12 years of funds to fly to the moon (PLEASE!) or they can send the Space Shuttle up and down, up and down, up and down, (sensing a pattern yet?) up and down, up and down, up and down, up and...
What reason could they possibly have for spending $100B on this?
Because that is NASA's budget. IIRC, NASA's budget used to be about $14 billion per year. Bush has given the budget a few small increases since then. Yet even at the figure I gave, we're still talking about spending $168 billion on NASA over the next 12 years.
There really isn't anything new in these figures. I don't know about anyone else, but I'd rather see that $100 billion go into getting to the moon than into flying the Space Shuttle up and down a few more times.
Just to be clear, this isn't new news. The CEV (Crew Exploration Vehicle) program has been designed from the beginning with orbital, trans-lunar, and lunar landing phases. What this article is about is an update on those existing plans. The bright side to this is that NASA is making real progress on the CEV program as opposed to making it a "miracle technology" that just need money poured into it as they have been so guilty of in the past. (Not that the CEV program doesn't need money. They need LOTS of money.)
The big changes since the inception of the program have been:
The death of the Orbital Space Plane idea, and the birth of the CEV concept.
The plan to use less expensive and potentially reusable capsule technology instead of today's combined engine/habitat technology.
The death of the "Spiral" plan of development. Griffin has made it clear to congress that he plans to trim the fat and do this in whatever way makes sense, not according to a military development schedule.
As a result of the abandoning of the spiral plan, NASA believes that they can have the Orbital phase hardware completed by 2008 instead of 2011.
A great deal of research is being done on the use of Nuclear Engines for the later trans-Mars phase.
IMHO, Bush's administration has done a reasonable job of making sure that we are on a viable track to returning to the moon and reaching Mars. My hope is that the next President who shows up doesn't dive in and try to change everything. The plan is good. It only needs some nursemaiding, not micromanagement from on high. Thankfully there's a great deal of pressure to replace the Space Shuttle, so the future President may be willing to just let NASA do their job.
(FYI, Wikipedia has been keeping extremely good track of CEV Development as it happens. While Wikipedia is not a news source, this particular article is a good place to go for the latest status of the project.)
No, this is an attempt to make you *pay* for Service Packs.
2008: Upgrade to Windows Vista version 2.0 for only $200! 2009: Upgrade to Windows Vista version 3.0 for only $225! 2010: Upgrade to Windows Vista version 4.0 for only $275! 2011: Upgrade to Windows Vista version 4.0 for only $350! 2012: Upgrade to Windows Vista version 5.0 for only $1000!
Maybe. There's quite a bit of evidence to suggest that he "secretly" runs a Mac, so why not FireFox?
and his "engineers" are buying copying, I mean, Innovating for the next version of Internet Explorer.
Doubtful. If you check out most of their work over at Channel 9, they're being quite arrogant about IE 7. They don't seem to want to be influenced by FireFox at all, and they seem to think that standards compliance should take a back seat to making IE "cooler".
That being said, there is one thing that everyone should keep in mind about IE 5.0. When it was released, IE 5 was the best browser in existance, bar none. It was light, it was fast, it was simple, it was straightforward, and it had real features that helped people. (Such as the ability to save passwords.) Microsoft never properly thanked SpyGlass for their browser technology, but Microsoft *did* take the browser experience to a whole new level.
It wasn't until Mozilla reached somewhere around the 0.8 version that any browser even tried to compete. Even Opera was kind of pathetic in comparison. By the time Mozilla hit 1.0 (and Opera finally got the lead out), IE had held the market for several years. It's only thanks to Microsoft's intentional attempts to sit still that Mozilla, Opera, and now Safari had a chance to play catch up.
Go learn the difference between blocks and sectors before you comment.
No, I'm well aware of the difference. I was having one of my temporary memory lapses and couldn't remember the term block. Since I was in a hurry, I used the word "Sector" and hoped no one would notice. Ah well.:-)
Blocks default to 4096 bytes, because this is convenient for the page cache;
That's what I said.
nothing stops you using a different size.
Bzzt. You need to use multiples of 512, otherwise the blocks and sectors won't line up properly.
For example, I have ext3 filesystems at work using 512 byte blocks (so the allocation unit is 512 bytes) on a system with 4096 byte pages.
And? I did say that 4K was normally used because it lines up nicely with the page sizes. If you use a different size for blocks, it will still run through the paging system, regardless.
ReiserFS tail-packing uses left-over space in blocks, and space that cannot be used as blocks.
What is "space that cannot be used as blocks"? Blocks are managed by the Linux Kernel. You can't muck with the block size you chose. (Though there has been some mutterings about making the last few blocks of an odd sized device accessable in Linux as a partial block.)
4K blocks is less efficient, but still works fine (which would not be true if the OS paged the memory to disk for writes, since the block would be accompanied by 12K of garbage.
You forget about read-ahead caching. For sequential I/O, the reading is run through the paging system to make read ahead more efficient. So the OS is *designed* to read (and potentially write depending on your kernel version) more than it needs. So it fills pages as necessary. Pages used for disk I/O are not the same pages used for Swap I/O, as that would create something of a mess.
Since the page is filled with the complete data from that portion of the disk drive, it can page out the correct data to disk. i.e. No 12K of garbage as you propose.
I *don't* know if the page sizes used between the file and swap systems are required to match up.
Reads and writes at the OS level can still be done on a single-sector basis; it's just inefficient, as each sector ends up filling a page in the cache, either with the other 7 sectors needed to make up one page, or with dummy data.
I'm not aware of any APIs that allow you to address a block device in a unit smaller than a block, but it's always possible that such an API has been added to recent kernels. I sincerely doubt you'd want to use direct sector addressing, though, since it would probably screw up the OS's attempts at block level locking.
On a side note, it's quite interesting to see SUN, who used to be *the* big player do anything to grab some press.
You act like this is new for Sun. Let's not forget that this is the same Sun that sent a boatload of exterminator trucks to the Windows 2000 launch just to remind everyone that Win2K had 65,000 bugs in it. Or the constant bickering between Sun and IBM.
IBM: We're going to *Eclipse* the competition.
Sun: Let's *shine some light* on IBM's claims.
Not to mention McNealy's comments about HP: "They make great printers!"
Not quite true. Filesystems like ReiserFS (v3 or v4) may use 4096 byte blocks for large files, but can pack several small files into single physical sectors (512 bytes).
Uh, no. As I understand it, ReiserFS sets aside sectors for packing in small files. Like to take a guess as to the size of those sectors? That's right, 4096 bytes. FFS/UFS does the same thing, making it far more space efficient than the DOS/Windows FAT and NTFS file systems that came later.
As I said, the reason for the 4K sectors is that the OS pages the memory to disk for writes. A page is 4096 bytes on most systems, so that's what's written.
Of course, the entire memmap scheme in Unix (through which most everything runs) is a pathetic attempt at emulating one of the more powerful features of Multics: Files are directly mapped to memory, making access to files the same as direct memory access. Perhaps not quite as fast, but even in Unix memmaps still tend to be faster than direct file I/O.
I just like dd_rescue, so I thought I'd pimp it here
On plain dd, bs=4096 runs the risk of not overwriting up to 3 sectors at the end of the disc.
It's not that much of a risk. Almost all file systems use 4096 byte sectors so that they align with the size of the memory pages. If you've got an uneven number of sectors, the file system probably isn't using them anyway.
Drop the "count=". dd will continue on until the entire file (which happens to be from an unlimited source to the entire disk) is written. Also, the default block size is 512, so you don't need to worry about that either. Though you may actually get better performance by using "bs=4096".
A standard format is usually a "quick" format. Which means that recovering the info is easy. You need to do a low-level format in order to actually destroy the data. Even then, there are no guarantees. Your best bet is to insert a Linux boot CD or floppy and run:
dd if=/dev/zero of=/dev/[drive name]
* Unformat was removed in Windows 95, so it doesn't work on modern machines. However, the existance of the command demonstrated that it was quite easy to restore the original file table to recover all the data. e.g. Back in the day, I accidentally reformatted a floppy that had data I wanted on it. A quick unformat later, the entire disk was restored.
The filename solution avoids most of the churnings.
And also limits the amount of information that can be stored. You're going to bump up against the upper-limit of the filename length, just from the subject. Add an email with a large number of To's or CC's, and your filename solution breaks down.
This sounds simplistic, as if the disk hardware and its natural latency were somehow absent from the picture. If it is instant, as you say, then there is also a fair chance that the same query would return instantly for a non-DBFS. Namely, because the block the information is in, is already cached...
Of course it's not truely instant, but it's close enough. Take the Spotlight search system as an example. It produces a list of files, as you type. For a comparison of performance, go to '/usr/bin' on a Unix system and attempt to use tab completion in BASH. Notice how slow BASH is at retrieving the results?
But, at some point the DBFS will also have to churn through the disk for a randomly chosen string in the body of the email message. Or, you could technically index everything,
Hallelujah, he finally gets it! Yes, index everything. Or more precisely, the hook for handling email files would divide the file up into keywords which would be added to the index. The amount of storage for this would be the one-time cost of the word plus 4-8 bytes for each instance of the word found across the entire filesystem.
You will want to use cache space for your index, right?
Correct. But in the absence of the data being cached, it's much faster to burst read the index than it is to read through every file. Ideally, the head would never leave the platter while reading in the index, as opposed to studying each file on disk. Worst case for head movement in this situation would be O(fragments) for the index and O(files*fragments) for studying each file.
Unless these are modelled as subdirectories so that they don't take up space in the filename.
Mess, mess, mess. Not to mention that file systems still often have limits on the size of the full path.
I doubt you'll do that, based on the fact that these are large chunks of mostly random data coming in, and you'll be spending all of your time updating the index with each email that comes in and wondering why your new server is so slow
Who's talking about servers? I'm talking about clients. (Although servers would work just fine as well.) And updating the index is a minor amount of data to commit. As I said, the cost of the word, plus a 4-8 byte cost for each instance on the filesystem.
Also, the DBFS has to read an extra index, a storage area a normal filesystem doesn't have to maintain, physically translate to, update, or use up cache space to store.
Except that a Database File System would be built to maintain, physically translate to, update, and use cache space to store these indexes. Remember, I'm not advocating the use of a database on top of a files ystem. I'm advocating a more advanced file system that extends the current indexing capabilities.
FYI, BeFS was a full database file system, HFS+ now has DBFS features, and NTFS has a great deal of DBFS features (despite Microsoft ignoring the features in OSes prior to Vista).
You were worried about a parser, but here you've got a larger, more complicated filesystem driver taking up space in precious RAM, butting up against kernelspace and single-threadedly stuck to one CPU.
None of the above. I realize that you decided my article was a snore-fest, but I actually suggested using FUSE to stick the file system in userspace. Which means that the process can be multi-threaded, multi-processor, and freely use pagable memory.
I still don't see why the webpage/GUI writer, for instance, would be forced to explicitly throw in a rename button on the client (this is supposed to be a record of delivery, not a workgroup editing effort).
You appeal to to struggle with complicated sentence constructions.
Appear, not appeal. Appeal is the legal practice of asking for a legal decision to be overturned. Appear is how something is perceived, especially in a visual sense.
I never said there was a court case, I say they would've won, if there had been a court case. (And they would've).
Let me repeat this. There was no court case. Period, end of story. Without that court case, there is NO WAY of knowing how it would have swung. As any lawyer can tell you, Firebird is a very common word, and the database vs. the web browser were in very different markets. In addition, there was no attempt at brand confusion through the use of similar logos.
So get this through your head: There was no court case. Therefore, your example is invalid.
try marketing your Micro-soft operating system and see how long that "but we had a hyphen!" argument holds up.
You might be able to get away with it if you use significantly different styling for the logos. e.g. Microcenter could cause brand confusion if they styled their brands in such a way as to make the consumer believe that they were a Microsoft company.
However, a judge would probably find that you were attempting to cause brand confusion based on the shear popularity of the Microsoft mark.
In this case, however, my understanding is that Google didn't learn of the mark until a month after they launched their service. In addition, the two services operate in different markets. So Google has a strong case in that the two services are unlikely to be confused, and that Google has been using the mark in good faith.
Doesn't matter. The Firebird database is a niche item, but they'd still have won a trademark case with Mozilla Firebird.
I wish people would stop repeating nonsense like this. As with many legal threats, there was no court case. Since there was no court case, there was no determination of brand validity. Since there was no determination of brand validity, there is no legal precident steming from the issue.
The most that could come out of it is that if Firebird (database) ever went to court over their name again, they could claim that Mozilla decided to settle because they believed in the validity of Firebird's claims. (In reality Mozilla just didn't want any trouble, so they picked a truely unique name.)
Arguably, though, you'd see much more of a performance gap if the applications were better designed to take advantage of the 64 bit power of the processor. That means not just a recompile as a 64 bit application, but having the app actually use 64 bit numbers whenever possible.
It's a bit like the jump to 32bit. When all we had was 16bit software to test, the performance numbers tended to be equal. Once the software started showing up that was written for 64bit processing, we started seeing a major performance gap.
How does a DBFS index materially differ in any way from the existing indexing system of filesystem i-nodes (index nodes anyone?:) directories, caches and buffers, in a way that would matter to this application?
The "index node" provides an index tree for a very simple type of query: The filesystem heirarchy. (This was addressed in the article I linked to.) However, the inodes provide no real information about a file other than its location, unless they are extended to include meta-data attributes. Using the email example, "To", "From", "CC", "Received", "Sent", and "Subject" are all meta-data fields you might expect to find in an email. With the meta-data, I can ask the index, "from:UnapprovedThought@gmail.com" and get back an instant result. Without the index, I have to churn through every email file on disk. Not to mention that I need to *parse* each file to find the info I'm looking for.
The scheme of using the filename does alleviate the situation somewhat, but it still is not tremendously fast (lots of I/O here), you still need to parse each filename, and it is limited in the number of fields it can contain.
It's not the size of your attachments but the wisdom of your indexing method:)
But you are advocating no index. I'm advocating an index built into the file system. Which is it?
And why would you want to have your front end permit renaming files?
You have no choice. If the user can see a file on disk, they can rename it. Your options are to extend the OS GUI to prevent the user from taking such action, or work with the user so that the client and the file system show consistent views. In a DBFS, the two *will* be consistent. So much so, that you may not even need an email client, or the client may be nothing more than a specialized version of the file browser.:-)
A very interesting post Mr. 10101001 10101001, but ultimately misguided.
I'd like to start out by asking what Linux Distribution you were talking about. Was it Gentoo? Mandrive? Ubuntu? Or did you mean all distros?
This is the moment when you make the primary mistake that screws up the rest of your post. I wasn't talking about any specific distribution, much less all distributions. I titled the article "Linux Distribution of the Future" for a reason. Specifically, because my suggestions are for new technology that doesn't exist yet. If existing distros wanted to pick up the technology, that would be up to them. But as a whole, I'm describing a distribution that doesn't yet exist.
Many people have accused me of suggesting that all distros should adopt my ideas. This has persisted no matter how often I repeat that I only want a single distribution to be internally consistent. From the third part of the original article:
The end result of this process is that control of the system APIs is taken away from the user. While many Linux purists would argue against such a step, it's important to note that I am not advocating taking this step for all distributions.
I understand that I may not have been clear on the point that I am only looking for my mythical distribution "of the future" to be internally consistent, but that is my position. As I stated in my article, one of the problems with the current situation is that a distribution can be upgraded or downgraded with any combination of APIs. So there is no true "Red Hat 9" or "Debian 3.1". It's whatever the user builds it to be. That is counterproductive in a Desktop system.
If you do, I'd suggest you do some development of your own. Maybe even ask a little nicer and be a little less demanding.
I find this comment to be a little bit offensive. I have asked nothing of anyone other than their attention. I have shared ideas, I have done research, I have taken extreme criticism, and yes I have gotten up on my soap box and preached on some of the issues I see in the community.
I could sit here and recount the software I've made freely available (public domain, no less) and the contributions I've made to free software projects, but I have nothing to prove. I've been slowly attempting to build a small group of volunteers to help me with the ideas I've presented. But they have volunteered. No one has been told or bossed around.
At the end of the day, however, that has nothing to do with the subject at hand. The subject at hand is that many of the Linux community are inadvertantly hindering the chances for their favorite OS on the open market. Poorer chances on the open market mean less vendor support. Less vendor support means fewer Linux jobs, fewer Linux hardware drivers, and fewer commercial ports of Linux applications. While the latter means little to some, the former two are extremely important.
This elitist attitude is pointless and counterproductive. If I can have an impact on it in any small way, shape, or form, then I will stand on my soapbox and preach. I may be a crazy loon to think I can help that way, but it's never stopped me before.:-)
Cmd-Shift-G (go to Folder)/usr/bin doubleclick on vim and you're up and running.
I just tried. The exact error message I received was 'There is no default Application specified to open the document "vi".' Please don't spread further FUD.
- most Linux users who'd support your ideas are probably already employed and have "bread and butter" jobs limiting their ability to contribute
This is the biggest problem. I myself haven't even been able to do much on it, because Real Life(TM) keeps interfering. (Oh, and poor SATA support in Linux hasn't helped either.)
- commercial Linux distros like selling subscription services, so removing the need for a package manager is probably going to turn them off to this idea
- Venture Capitalists are going to ask how you'll make money from this, but the idea is to make Linux so easy that it doesn't really need extra support, and since it's Linux, most people can just burn CDs for each other without having to pay for anything
I actually have an extensive business plan for both of these. But I'm not talking about it until I can grab the ear of someone with money and lay it out for them. Or I get too damn tired of chasing things around and decide to tell the world how to make it work. Whichever comes first.:-)
Believe it or not, there is potential for making money off of software. It's just not in the Microsoft sense. More in the Apple sense. <gump>And that's all I got ta' say about that.</gump>;-)
That doesn't mean anything if every *regular* user is in the sudoers list.
Only the first user added to the system is automatically given sudo permissions. All other users need the little "give admin privledges" checkbox ticked.
Surprisingly, there are actually things you *can't* do if you have sudo privledges. For example, your username *can't* be used for remote login should you enable services such as SMB and NFS.
"sudo sh" is even better than having a root password, since regular users don't tend to have very good passwords.
Still very difficult. The attacking program needs a good method for guessing passwords. IIRC, sudo increases the pause after every failed attempt, so it doesn't take long before it becomes effectively impossible for the virus to gain access. A virus could sit on the system for months, and still not manage to guess even the stupidest password.:-)
As I said, "according to some numbers." Marketshare is a difficult computation, because there's a lot of factors that can play into it. So depending on how you run the numbers, you're going to get different results. It's a bit like trying to determine which web browser is the most popular. Numbers tend to vary wildly. However, they do point to indications of increasing or decreasing.
So there's nothing I said that's incorrect. Only your attempts to twist what I said are incorrect. If you read the articles, the differences in methodology are apparent.
Lets do the numbers and say 1000 computers total (just for ease of math)
Nice sleight of hand there. A lot like the missing dollar paradox. But just like the paradox, we have absolute numbers that do work out in the end. According to the first link, Apple has shipped nearly 50 million computers last quarter. The article gives exact figures for the growth, so pulling that "BSD is dying" math doesn't hold water. (The amazing Kreskin predicted it!)
I think your best bet here is to try and convince other people I am a troll or to say you were trolling me to save face.
I'll never understand why you trolls think that garbage works. Claiming you're not a troll in an obvious troll is the surest sign that you *are* a troll. So have fun trolling, Mr. Troll.
Slashdot Mirror
It's not as hard as you think. NASA's 2006 budget is $16 billion dollars. That money is already in the congressional budget. Now NASA can use their next 12 years of funds to fly to the moon (PLEASE!) or they can send the Space Shuttle up and down, up and down, up and down, (sensing a pattern yet?) up and down, up and down, up and down, up and...
Well, you get the idea.
What reason could they possibly have for spending $100B on this?
Because that is NASA's budget. IIRC, NASA's budget used to be about $14 billion per year. Bush has given the budget a few small increases since then. Yet even at the figure I gave, we're still talking about spending $168 billion on NASA over the next 12 years.
There really isn't anything new in these figures. I don't know about anyone else, but I'd rather see that $100 billion go into getting to the moon than into flying the Space Shuttle up and down a few more times.
The big changes since the inception of the program have been:
IMHO, Bush's administration has done a reasonable job of making sure that we are on a viable track to returning to the moon and reaching Mars. My hope is that the next President who shows up doesn't dive in and try to change everything. The plan is good. It only needs some nursemaiding, not micromanagement from on high. Thankfully there's a great deal of pressure to replace the Space Shuttle, so the future President may be willing to just let NASA do their job.
(FYI, Wikipedia has been keeping extremely good track of CEV Development as it happens. While Wikipedia is not a news source, this particular article is a good place to go for the latest status of the project.)
No, this is an attempt to make you *pay* for Service Packs.
2008: Upgrade to Windows Vista version 2.0 for only $200!
2009: Upgrade to Windows Vista version 3.0 for only $225!
2010: Upgrade to Windows Vista version 4.0 for only $275!
2011: Upgrade to Windows Vista version 4.0 for only $350!
2012: Upgrade to Windows Vista version 5.0 for only $1000!
Wonder if, secretly, Bill Gates runs Firefox
Maybe. There's quite a bit of evidence to suggest that he "secretly" runs a Mac, so why not FireFox?
and his "engineers" are buying copying, I mean, Innovating for the next version of Internet Explorer.
Doubtful. If you check out most of their work over at Channel 9, they're being quite arrogant about IE 7. They don't seem to want to be influenced by FireFox at all, and they seem to think that standards compliance should take a back seat to making IE "cooler".
That being said, there is one thing that everyone should keep in mind about IE 5.0. When it was released, IE 5 was the best browser in existance, bar none. It was light, it was fast, it was simple, it was straightforward, and it had real features that helped people. (Such as the ability to save passwords.) Microsoft never properly thanked SpyGlass for their browser technology, but Microsoft *did* take the browser experience to a whole new level.
It wasn't until Mozilla reached somewhere around the 0.8 version that any browser even tried to compete. Even Opera was kind of pathetic in comparison. By the time Mozilla hit 1.0 (and Opera finally got the lead out), IE had held the market for several years. It's only thanks to Microsoft's intentional attempts to sit still that Mozilla, Opera, and now Safari had a chance to play catch up.
Go learn the difference between blocks and sectors before you comment.
:-)
No, I'm well aware of the difference. I was having one of my temporary memory lapses and couldn't remember the term block. Since I was in a hurry, I used the word "Sector" and hoped no one would notice. Ah well.
Blocks default to 4096 bytes, because this is convenient for the page cache;
That's what I said.
nothing stops you using a different size.
Bzzt. You need to use multiples of 512, otherwise the blocks and sectors won't line up properly.
For example, I have ext3 filesystems at work using 512 byte blocks (so the allocation unit is 512 bytes) on a system with 4096 byte pages.
And? I did say that 4K was normally used because it lines up nicely with the page sizes. If you use a different size for blocks, it will still run through the paging system, regardless.
ReiserFS tail-packing uses left-over space in blocks, and space that cannot be used as blocks.
What is "space that cannot be used as blocks"? Blocks are managed by the Linux Kernel. You can't muck with the block size you chose. (Though there has been some mutterings about making the last few blocks of an odd sized device accessable in Linux as a partial block.)
4K blocks is less efficient, but still works fine (which would not be true if the OS paged the memory to disk for writes, since the block would be accompanied by 12K of garbage.
You forget about read-ahead caching. For sequential I/O, the reading is run through the paging system to make read ahead more efficient. So the OS is *designed* to read (and potentially write depending on your kernel version) more than it needs. So it fills pages as necessary. Pages used for disk I/O are not the same pages used for Swap I/O, as that would create something of a mess.
Since the page is filled with the complete data from that portion of the disk drive, it can page out the correct data to disk. i.e. No 12K of garbage as you propose.
I *don't* know if the page sizes used between the file and swap systems are required to match up.
[info]
[more info]
[more, but older, info]
Reads and writes at the OS level can still be done on a single-sector basis; it's just inefficient, as each sector ends up filling a page in the cache, either with the other 7 sectors needed to make up one page, or with dummy data.
I'm not aware of any APIs that allow you to address a block device in a unit smaller than a block, but it's always possible that such an API has been added to recent kernels. I sincerely doubt you'd want to use direct sector addressing, though, since it would probably screw up the OS's attempts at block level locking.
I just search for "AKAImBatman", and I got 19 results; most from this blog "The Man Also Known as 'I'm Batman'"! Whoo hoo! I'm famous!
...
Err... wait a moment...
You act like this is new for Sun. Let's not forget that this is the same Sun that sent a boatload of exterminator trucks to the Windows 2000 launch just to remind everyone that Win2K had 65,000 bugs in it. Or the constant bickering between Sun and IBM.
Not to mention McNealy's comments about HP: "They make great printers!"
Nope, nothing new under the Sun.
Not quite true. Filesystems like ReiserFS (v3 or v4) may use 4096 byte blocks for large files, but can pack several small files into single physical sectors (512 bytes).
:-)
Uh, no. As I understand it, ReiserFS sets aside sectors for packing in small files. Like to take a guess as to the size of those sectors? That's right, 4096 bytes. FFS/UFS does the same thing, making it far more space efficient than the DOS/Windows FAT and NTFS file systems that came later.
As I said, the reason for the 4K sectors is that the OS pages the memory to disk for writes. A page is 4096 bytes on most systems, so that's what's written.
Of course, the entire memmap scheme in Unix (through which most everything runs) is a pathetic attempt at emulating one of the more powerful features of Multics: Files are directly mapped to memory, making access to files the same as direct memory access. Perhaps not quite as fast, but even in Unix memmaps still tend to be faster than direct file I/O.
I just like dd_rescue, so I thought I'd pimp it here
As I said, neat utility.
On plain dd, bs=4096 runs the risk of not overwriting up to 3 sectors at the end of the disc.
:-)
It's not that much of a risk. Almost all file systems use 4096 byte sectors so that they align with the size of the memory pages. If you've got an uneven number of sectors, the file system probably isn't using them anyway.
I like the dd_rescue idea, though.
Drop the "count=". dd will continue on until the entire file (which happens to be from an unlimited source to the entire disk) is written. Also, the default block size is 512, so you don't need to worry about that either. Though you may actually get better performance by using "bs=4096".
About as easy as "unformat c:"*.
A standard format is usually a "quick" format. Which means that recovering the info is easy. You need to do a low-level format in order to actually destroy the data. Even then, there are no guarantees. Your best bet is to insert a Linux boot CD or floppy and run:
dd if=/dev/zero of=/dev/[drive name]
* Unformat was removed in Windows 95, so it doesn't work on modern machines. However, the existance of the command demonstrated that it was quite easy to restore the original file table to recover all the data. e.g. Back in the day, I accidentally reformatted a floppy that had data I wanted on it. A quick unformat later, the entire disk was restored.
The filename solution avoids most of the churnings.
And also limits the amount of information that can be stored. You're going to bump up against the upper-limit of the filename length, just from the subject. Add an email with a large number of To's or CC's, and your filename solution breaks down.
This sounds simplistic, as if the disk hardware and its natural latency were somehow absent from the picture. If it is instant, as you say, then there is also a fair chance that the same query would return instantly for a non-DBFS. Namely, because the block the information is in, is already cached...
Of course it's not truely instant, but it's close enough. Take the Spotlight search system as an example. It produces a list of files, as you type. For a comparison of performance, go to '/usr/bin' on a Unix system and attempt to use tab completion in BASH. Notice how slow BASH is at retrieving the results?
But, at some point the DBFS will also have to churn through the disk for a randomly chosen string in the body of the email message. Or, you could technically index everything,
Hallelujah, he finally gets it! Yes, index everything. Or more precisely, the hook for handling email files would divide the file up into keywords which would be added to the index. The amount of storage for this would be the one-time cost of the word plus 4-8 bytes for each instance of the word found across the entire filesystem.
You will want to use cache space for your index, right?
Correct. But in the absence of the data being cached, it's much faster to burst read the index than it is to read through every file. Ideally, the head would never leave the platter while reading in the index, as opposed to studying each file on disk. Worst case for head movement in this situation would be O(fragments) for the index and O(files*fragments) for studying each file.
Unless these are modelled as subdirectories so that they don't take up space in the filename.
Mess, mess, mess. Not to mention that file systems still often have limits on the size of the full path.
I doubt you'll do that, based on the fact that these are large chunks of mostly random data coming in, and you'll be spending all of your time updating the index with each email that comes in and wondering why your new server is so slow
Who's talking about servers? I'm talking about clients. (Although servers would work just fine as well.) And updating the index is a minor amount of data to commit. As I said, the cost of the word, plus a 4-8 byte cost for each instance on the filesystem.
Also, the DBFS has to read an extra index, a storage area a normal filesystem doesn't have to maintain, physically translate to, update, or use up cache space to store.
Except that a Database File System would be built to maintain, physically translate to, update, and use cache space to store these indexes. Remember, I'm not advocating the use of a database on top of a files ystem. I'm advocating a more advanced file system that extends the current indexing capabilities.
FYI, BeFS was a full database file system, HFS+ now has DBFS features, and NTFS has a great deal of DBFS features (despite Microsoft ignoring the features in OSes prior to Vista).
You were worried about a parser, but here you've got a larger, more complicated filesystem driver taking up space in precious RAM, butting up against kernelspace and single-threadedly stuck to one CPU.
None of the above. I realize that you decided my article was a snore-fest, but I actually suggested using FUSE to stick the file system in userspace. Which means that the process can be multi-threaded, multi-processor, and freely use pagable memory.
I still don't see why the webpage/GUI writer, for instance, would be forced to explicitly throw in a rename button on the client (this is supposed to be a record of delivery, not a workgroup editing effort).
All the user has t
You appeal to to struggle with complicated sentence constructions.
Appear, not appeal. Appeal is the legal practice of asking for a legal decision to be overturned. Appear is how something is perceived, especially in a visual sense.
I never said there was a court case, I say they would've won, if there had been a court case. (And they would've).
Let me repeat this. There was no court case. Period, end of story. Without that court case, there is NO WAY of knowing how it would have swung. As any lawyer can tell you, Firebird is a very common word, and the database vs. the web browser were in very different markets. In addition, there was no attempt at brand confusion through the use of similar logos.
So get this through your head: There was no court case. Therefore, your example is invalid.
try marketing your Micro-soft operating system and see how long that "but we had a hyphen!" argument holds up.
You might be able to get away with it if you use significantly different styling for the logos. e.g. Microcenter could cause brand confusion if they styled their brands in such a way as to make the consumer believe that they were a Microsoft company.
However, a judge would probably find that you were attempting to cause brand confusion based on the shear popularity of the Microsoft mark.
In this case, however, my understanding is that Google didn't learn of the mark until a month after they launched their service. In addition, the two services operate in different markets. So Google has a strong case in that the two services are unlikely to be confused, and that Google has been using the mark in good faith.
Doesn't matter. The Firebird database is a niche item, but they'd still have won a trademark case with Mozilla Firebird.
I wish people would stop repeating nonsense like this. As with many legal threats, there was no court case. Since there was no court case, there was no determination of brand validity. Since there was no determination of brand validity, there is no legal precident steming from the issue.
The most that could come out of it is that if Firebird (database) ever went to court over their name again, they could claim that Mozilla decided to settle because they believed in the validity of Firebird's claims. (In reality Mozilla just didn't want any trouble, so they picked a truely unique name.)
Arguably, though, you'd see much more of a performance gap if the applications were better designed to take advantage of the 64 bit power of the processor. That means not just a recompile as a 64 bit application, but having the app actually use 64 bit numbers whenever possible.
It's a bit like the jump to 32bit. When all we had was 16bit software to test, the performance numbers tended to be equal. Once the software started showing up that was written for 64bit processing, we started seeing a major performance gap.
How does a DBFS index materially differ in any way from the existing indexing system of filesystem i-nodes (index nodes anyone? :) directories, caches and buffers, in a way that would matter to this application?
:)
:-)
The "index node" provides an index tree for a very simple type of query: The filesystem heirarchy. (This was addressed in the article I linked to.) However, the inodes provide no real information about a file other than its location, unless they are extended to include meta-data attributes. Using the email example, "To", "From", "CC", "Received", "Sent", and "Subject" are all meta-data fields you might expect to find in an email. With the meta-data, I can ask the index, "from:UnapprovedThought@gmail.com" and get back an instant result. Without the index, I have to churn through every email file on disk. Not to mention that I need to *parse* each file to find the info I'm looking for.
The scheme of using the filename does alleviate the situation somewhat, but it still is not tremendously fast (lots of I/O here), you still need to parse each filename, and it is limited in the number of fields it can contain.
It's not the size of your attachments but the wisdom of your indexing method
But you are advocating no index. I'm advocating an index built into the file system. Which is it?
And why would you want to have your front end permit renaming files?
You have no choice. If the user can see a file on disk, they can rename it. Your options are to extend the OS GUI to prevent the user from taking such action, or work with the user so that the client and the file system show consistent views. In a DBFS, the two *will* be consistent. So much so, that you may not even need an email client, or the client may be nothing more than a specialized version of the file browser.
A very interesting post Mr. 10101001 10101001, but ultimately misguided.
:-)
I'd like to start out by asking what Linux Distribution you were talking about. Was it Gentoo? Mandrive? Ubuntu? Or did you mean all distros?
This is the moment when you make the primary mistake that screws up the rest of your post. I wasn't talking about any specific distribution, much less all distributions. I titled the article "Linux Distribution of the Future" for a reason. Specifically, because my suggestions are for new technology that doesn't exist yet. If existing distros wanted to pick up the technology, that would be up to them. But as a whole, I'm describing a distribution that doesn't yet exist.
Many people have accused me of suggesting that all distros should adopt my ideas. This has persisted no matter how often I repeat that I only want a single distribution to be internally consistent. From the third part of the original article:
The end result of this process is that control of the system APIs is taken away from the user. While many Linux purists would argue against such a step, it's important to note that I am not advocating taking this step for all distributions.
I understand that I may not have been clear on the point that I am only looking for my mythical distribution "of the future" to be internally consistent, but that is my position. As I stated in my article, one of the problems with the current situation is that a distribution can be upgraded or downgraded with any combination of APIs. So there is no true "Red Hat 9" or "Debian 3.1". It's whatever the user builds it to be. That is counterproductive in a Desktop system.
If you do, I'd suggest you do some development of your own. Maybe even ask a little nicer and be a little less demanding.
I find this comment to be a little bit offensive. I have asked nothing of anyone other than their attention. I have shared ideas, I have done research, I have taken extreme criticism, and yes I have gotten up on my soap box and preached on some of the issues I see in the community.
I could sit here and recount the software I've made freely available (public domain, no less) and the contributions I've made to free software projects, but I have nothing to prove. I've been slowly attempting to build a small group of volunteers to help me with the ideas I've presented. But they have volunteered. No one has been told or bossed around.
At the end of the day, however, that has nothing to do with the subject at hand. The subject at hand is that many of the Linux community are inadvertantly hindering the chances for their favorite OS on the open market. Poorer chances on the open market mean less vendor support. Less vendor support means fewer Linux jobs, fewer Linux hardware drivers, and fewer commercial ports of Linux applications. While the latter means little to some, the former two are extremely important.
This elitist attitude is pointless and counterproductive. If I can have an impact on it in any small way, shape, or form, then I will stand on my soapbox and preach. I may be a crazy loon to think I can help that way, but it's never stopped me before.
10.2.6 - Doesn't work. It would scare the hell out of me if it actually works in later versions. :-/
Touche
Cmd-Shift-G (go to Folder) /usr/bin
doubleclick on vim and you're up and running.
I just tried. The exact error message I received was 'There is no default Application specified to open the document "vi".' Please don't spread further FUD.
- most Linux users who'd support your ideas are probably already employed and have "bread and butter" jobs limiting their ability to contribute
:-)
;-)
This is the biggest problem. I myself haven't even been able to do much on it, because Real Life(TM) keeps interfering. (Oh, and poor SATA support in Linux hasn't helped either.)
- commercial Linux distros like selling subscription services, so removing the need for a package manager is probably going to turn them off to this idea
- Venture Capitalists are going to ask how you'll make money from this, but the idea is to make Linux so easy that it doesn't really need extra support, and since it's Linux, most people can just burn CDs for each other without having to pay for anything
I actually have an extensive business plan for both of these. But I'm not talking about it until I can grab the ear of someone with money and lay it out for them. Or I get too damn tired of chasing things around and decide to tell the world how to make it work. Whichever comes first.
Believe it or not, there is potential for making money off of software. It's just not in the Microsoft sense. More in the Apple sense. <gump>And that's all I got ta' say about that.</gump>
That doesn't mean anything if every *regular* user is in the sudoers list.
:-)
Only the first user added to the system is automatically given sudo permissions. All other users need the little "give admin privledges" checkbox ticked.
Surprisingly, there are actually things you *can't* do if you have sudo privledges. For example, your username *can't* be used for remote login should you enable services such as SMB and NFS.
"sudo sh" is even better than having a root password, since regular users don't tend to have very good passwords.
Still very difficult. The attacking program needs a good method for guessing passwords. IIRC, sudo increases the pause after every failed attempt, so it doesn't take long before it becomes effectively impossible for the virus to gain access. A virus could sit on the system for months, and still not manage to guess even the stupidest password.
Anything that doesn't kill me, only makes me stronger. :-)
So which is it.
As I said, "according to some numbers." Marketshare is a difficult computation, because there's a lot of factors that can play into it. So depending on how you run the numbers, you're going to get different results. It's a bit like trying to determine which web browser is the most popular. Numbers tend to vary wildly. However, they do point to indications of increasing or decreasing.
So there's nothing I said that's incorrect. Only your attempts to twist what I said are incorrect. If you read the articles, the differences in methodology are apparent.
Lets do the numbers and say 1000 computers total (just for ease of math)
Nice sleight of hand there. A lot like the missing dollar paradox. But just like the paradox, we have absolute numbers that do work out in the end. According to the first link, Apple has shipped nearly 50 million computers last quarter. The article gives exact figures for the growth, so pulling that "BSD is dying" math doesn't hold water. (The amazing Kreskin predicted it!)
I think your best bet here is to try and convince other people I am a troll or to say you were trolling me to save face.
I'll never understand why you trolls think that garbage works. Claiming you're not a troll in an obvious troll is the surest sign that you *are* a troll. So have fun trolling, Mr. Troll.
(tips hat) Good day.