These are very biased news and in fact they are wrong.
For starters, only the first submarine has a floatability problem. The other submarines in the series are larger, therefore they have no problem.
Now, why has the fist submarine (the original design) a floatability problem? Because the Navy asked for more equipment (electronic equipment, weapons, etc) and more comfortable cabins for the sailors than originally planned.
It is not a design problem but a modifications problem and this is very very very frequent in large projects, especially if military.
The changes have been taken into account in the design for the second and subsequent submarines (S81, S82, etc). The first submarine (S80) will be fixed by making it a bit longer and adding some floating aids.
Source: I work in this project.
Next time you want to say stupid things about very serious projects, please warn us you are drunk.
If this is the case, then I don't see the point. Filesystems already in use support TRIM.
Just because you send TRIM down it doesn't mean that the device can erase the block. The erase block size in NAND is usually 256KB or larger. Using 256KB as IO block is just crazy, drivers use something like 16KB or 32KB. The filesystem has to be aware of the erase block size so it can send down TRIM command for an aligned and contiguous 256KB block, then the device can go on and erase it.
SSDs are NAND, but they are not bare NAND. They have control circuitry which manages the problems with NAND (e.g. bad blocks), and presents the drive as a contiguous block of good storage.
These filesystems are all for bare NAND, not SSDs, which include NAND, but are not bare NAND.
How can this be "Informative", it's plain wrong. f2fs works on top of block devices.
No. SSDs present themselves to the OS as contiguous block devices. Filesystems intended for bare NAND flash like jffs(2), yaffs, and this new F2Fs would be totally useless for SSDs. They're intended for bare NAND, which SSDs are not.
You're wrong
f2fs work on top of block devices. f2fs sends TRIM (ATA command) down to the device. Bare NAND flash doesn't grok ATA commands.
1. It has the best (claimed) battery life (when used with the dock) 18h. Kal-El, with 40Mbps video capacity, should (in theory) handle any kind of HD video including BR rips. NEON+quadcore should be good for games (NEON wasn't supported in Tegra-2).
2. The 4+1 is transparent to the OS, according to Nvidia.
3. Linux kernel will scale and spread tasks among avail cores. whether a game will spread intensive jobs to multi-threads? well it depends on the game...
4. Do you play games all the time? well get a console then.
The kernel devs don't do development on master! However, git's fast-forward-merge will, by default, push development/intermediate commits onto master. Those intermediate commits are extremely useful for code-inspection/code-review and bisect-based debugging. They're are not meant for starting a new dev branch and that why they're not tagged! There's nothing new or interesting in that article other than a bunch stupid comments at the bottom. The whole thing smells like a disguised advertising for PlasticSCM
...the very corporate Red Hat Desktop 4, could prove a sensible option for companies with large numbers of desktops. ...Our Editor's Choice for the small business, however, is the solid, well integrated and free Ubuntu Linux 5.1.
first you claimed "synchronized" methods can sync across JVM boundary. once, proven to be wrong, you came up with java.nio. Now, please enlight us how java.nio can do inter-JVMs mutual exclusion?
And how is it better than pthread mutex (with NPTL), which is very fast (on non-contention path, it's only dozen instructions no syscall) and provides inter-PROCESS mutual-exclusion.
We not talking about thread here, the article is abound inter-PROCESS communication.
1) shm_open(2) is already mentioned in the 2nd post.
2) dont u know that NPTL is already doing this for u? On fast-path, NPTL's posix mutex just do atomic operations and avoid doing syscall. Stick to the standard API and let the platform guys (libc, kernel,...) do the optimization. They're smarter than u.
3) u dont want to do this, seriously! if futex is that consummable by the public, then why did the glibc guy write a looooooong paper describing howto use futex.
The article is about shared-mem and synchronization accross process boundary! In Java that would mean: object that are shared between VMs; methods are are serialized across VM boundary.
I think he explained it before on the list, for him a CMS is:
a system to manage and manipulate changesets. i.e. from the (atomic) unit of change is the changeset and not the file version.
history-sensitive merge and multi-strategy merge.
I've never used arch but the two CMS that I used, prcs and UCM/ClearCase, both exhibit the above properties. I really like prcs especially for small local (over nfs) projects.
According to the judge, placing files on a shared directory does not amount to
distribution of the files. Before it constitutes distribution, he said, there must be a positive act by the owner of the shared directory, such as sending out copies of the files or advertising that they are available for downloading.
"I cannot see a real difference between a library that places a photocopy machine in a room full of copyrighted material and a computer user that places a personal copy on a shared directory linked to a P2P service," he wrote. "In either case the preconditions to copying and infringement are set up but the element of authorization is missing."
Slashdot Mirror
These are very biased news and in fact they are wrong. For starters, only the first submarine has a floatability problem. The other submarines in the series are larger, therefore they have no problem. Now, why has the fist submarine (the original design) a floatability problem? Because the Navy asked for more equipment (electronic equipment, weapons, etc) and more comfortable cabins for the sailors than originally planned. It is not a design problem but a modifications problem and this is very very very frequent in large projects, especially if military. The changes have been taken into account in the design for the second and subsequent submarines (S81, S82, etc). The first submarine (S80) will be fixed by making it a bit longer and adding some floating aids. Source: I work in this project. Next time you want to say stupid things about very serious projects, please warn us you are drunk.
J D Exposito
If this is the case, then I don't see the point. Filesystems already in use support TRIM.
Just because you send TRIM down it doesn't mean that the device can erase the block. The erase block size in NAND is usually 256KB or larger. Using 256KB as IO block is just crazy, drivers use something like 16KB or 32KB. The filesystem has to be aware of the erase block size so it can send down TRIM command for an aligned and contiguous 256KB block, then the device can go on and erase it.
SSDs are NAND, but they are not bare NAND. They have control circuitry which manages the problems with NAND (e.g. bad blocks), and presents the drive as a contiguous block of good storage.
These filesystems are all for bare NAND, not SSDs, which include NAND, but are not bare NAND.
How can this be "Informative", it's plain wrong. f2fs works on top of block devices.
No. SSDs present themselves to the OS as contiguous block devices. Filesystems intended for bare NAND flash like jffs(2), yaffs, and this new F2Fs would be totally useless for SSDs. They're intended for bare NAND, which SSDs are not.
You're wrong
f2fs work on top of block devices. f2fs sends TRIM (ATA command) down to the device. Bare NAND flash doesn't grok ATA commands.
So the OP means: "Get an iPad so you can look like your grandmother" ! hmmm.
Does your notebook last 12h, 16h or 18h? An out-of-battery notebook cannot do anything.
at 21", it would be a tabletop and not a tablet.
1. It has the best (claimed) battery life (when used with the dock) 18h. Kal-El, with 40Mbps video capacity, should (in theory) handle any kind of HD video including BR rips. NEON+quadcore should be good for games (NEON wasn't supported in Tegra-2).
2. The 4+1 is transparent to the OS, according to Nvidia.
3. Linux kernel will scale and spread tasks among avail cores. whether a game will spread intensive jobs to multi-threads? well it depends on the game...
4. Do you play games all the time? well get a console then.
make xconfig!!!!
Then you probably can claim that Linux is written partly in bourne shell.
The kernel devs don't do development on master! However, git's fast-forward-merge will, by default, push development/intermediate commits onto master. Those intermediate commits are extremely useful for code-inspection/code-review and bisect-based debugging. They're are not meant for starting a new dev branch and that why they're not tagged! There's nothing new or interesting in that article other than a bunch stupid comments at the bottom. The whole thing smells like a disguised advertising for PlasticSCM
http://ipex-infotech-inc.tradenote.net/
first you claimed "synchronized" methods can sync across JVM boundary. once, proven to be wrong, you came up with java.nio. Now, please enlight us how java.nio can do inter-JVMs mutual exclusion?
And how is it better than pthread mutex (with NPTL), which is very fast (on non-contention path, it's only dozen instructions no syscall) and provides inter-PROCESS mutual-exclusion.
We not talking about thread here, the article is abound inter-PROCESS communication.
you forgot xxxBSD and Gentoo.
1) shm_open(2) is already mentioned in the 2nd post.
...) do the optimization. They're smarter than u.
2) dont u know that NPTL is already doing this for u? On fast-path, NPTL's posix mutex just do atomic operations and avoid doing syscall. Stick to the standard API and let the platform guys (libc, kernel,
3) u dont want to do this, seriously! if futex is that consummable by the public, then why did the glibc guy write a looooooong paper describing howto use futex.
The article is about shared-mem and synchronization accross process boundary! In Java that would mean: object that are shared between VMs; methods are are serialized across VM boundary.
some1 should tell the authors to rtfm.
$ man shm_open
I've never used arch but the two CMS that I used, prcs and UCM/ClearCase, both exhibit the above properties. I really like prcs especially for small local (over nfs) projects.
http://www.computerworld.com.au/index.php/id;13062 81842;fp;16;fpid;0
it's good for google's giant farm, it should be good for any lab.
It might be mistaken as a description of Scheme's features.
--