for $each in *glob.pattern* ; do
command "$each"
mv "$each" "$(echo \"$each\" | sed -e s/stuff/replace)"... done
The only extra quoting necessary is in commands with variable substitution. And (while it may seem confusing), that syntax works even when the filenames have quotes internally. The double quotes identifies the contents to be treated as a single token with interpolation to be performed before passing on to ``command'', which is what you wanted.
Also the $() syntax is your friend. But remember to give it ""s too, you don't want it to expand it AND THEN tokenize it.
I'm not a DBA by any stretch. Yet I've gotten Oracle 9i and 10g humming quite nicely on RHEL3 and 4 (WS mind you), Fedora, and SLES 8 (United Linux). On x86 and x86_64. 9iR2 on RHEL 3 was a bit of a pain in the ass on AMD64 during install time, but once you got over a few humps you didn't have to worry about it again.
Solaris installs usually went smoother, but woe unto thee who neglected to install 32-bit userland packages on a 64-bit install.:-/ Excuse me for being picky about package selection!
RHEL is huge. Really, massively fucking huge. It encompasses about 4 times as much stuff as you'd see in a Solaris install, and it supports a much wider range of hardware.
Red Hat should change their support contract structure.
Tier 1: Security updates and access to beta patches
Tier 2: Customer support for the following packages: * The Kernel (hardware/stability issues) * Bugs in RH-written tools (Anaconda, Kudzu, system-config-*, rhgb, etc.) * Bugs in RH-modified packages relating to basic system services (firstboot, sysvinit, auditing, etc.)
Tier 3: Everything in Tier 2 + packages in "Base System", Dev Tools, Net Servers, and the Red Hat-branded packages (Postgres, JBoss, ClusterFS, etc.)
Tier 4: Everything in Tier 3 + the rest of the distro (mostly user-land stuff)
Most businesses only really need Tier 1 or 2. They probably have their own ideas about everything else they want to run (Oracle, MySQL, SAP, whatever). And anything beyond Tier 2 is really outside a lot of what the RH developers focus on, so the support is going to be shitty anyway).
By offering Tier 3 at the current offering price, Tier 4 at an increased price, and Tier 2 somewhere in between the current supported and un-supported rates, I think Red Hat could improve their responsiveness and be able to hire more people to improve support's response time.
As it is, their support is probably tied up in bugs relating to some included packages that aren't "core" but they have to support anyway by the virtue of including them. Such a tiering structure could make better use of support resources.
The real problem with Red-Hat is the legacy of its package management system; that turd's been polished so hard that you can see your face in it, but nevertheless remains a turd.
RPM is hardly legacy. It's pretty damn feature-complete. Care to explain what the issue with it is?
I always liked that kinda construction, and it goes back to days of oldskool hip hop.
So you take that components of your mash-ups and title it, you know: Mario vs. London Philharmonic or whatever you've got going on in your track. Unfortunately saying: "I like to compose Vs. (versus)" sounds kinda like verses or "I like to write lyrics".
I think if you avoid certain verbs before "versus" (drop, write, compose), and stick to more descriptive ones (track, mix, splice).
Shit, I like that last one. "I really enjoy splicin' versus."
That being said, that means every device would have to have carry a PCI bus emulation layer with it. OS's don't know how to negotiate resources unless it looks like its connected on a well-known logical bus.
Unless you've got some magic "platform" driver that probe-detects it and works without resource allocation (you'd have to negotiate your IRQ for OOB notification through some OS-negotiated process... Hello PnP!)
"fell on" is a verb construction that demands an object (satellite-framed verb). You can't omit the object of the preposition in that case. "reading" is a verb that implies an object (text, books). Therefore the pronoun is implied (book mentioned earlier in the sentence).
It's slow to write Only if you allow partial writes (make sure you use a correctly configured filesystem). Okay so it's still N% slower, but you've got caching and you'll probably hit the limit of your bus first anyway. if you lose a disk then read performance is significantly degraded until you get another Always have spare disks. I like to use the baker's dozen rule... for every 12 you buy, get a 13th. rebuilding is slow True. But modern systems (software RAID) let you tune the rebuild performance. Also, you should consider the following: If you get a failed disk in a RAID (any RAID), the next thing you should do BEFORE a rebuild is to MAKE A BACKUP. Because a rebuild is write-intensive and could trigger further failures if you're having disk remapping issues on your drives.
and if you get an unreadable sector during rebuilding you'll probably lose your entire array. For this reason (and the clustered failure scenario mentioned above) you want to use drives that have functioning SMART implementation and that you know do internal sector remapping. Do research on your drives before you buy them. And replace disks as before they reach the 50% mark on remapped data.
Even 1gbps is a whole fucking lot of sustained disk traffic. The example is hyperbolic.
You're better off using multiple RAID5s instead one large one, or better yet, using JFS or something that understands stripe sizes so it doesn't cause unnecessary parity reads for partial writes.
RAID5 can cause extra bus traffic to and from the controller. You need to check to see if your bottleneck is the card itself when you like 8+ drives attached. It helps if you have more than one controller on seperate busses and you can stripe across them RAID50-style. (Recommended on Opteron based systems with multiple CPUs and MCPs)
We run very "enterprise" setups where I work and you're right, it's "enterprisey" to go full on hardware RAID. And deal with all the headaches that leads to:
1) Poor OS integration ** 3Ware ** Dell PERC ** Adaptec need I go on? You get alarms coming from inside the unit and you have no idea what the fuck is going on until you reboot and drop into the BIOS. It's only recently that 3Ware started shipping a WBEM data source that could let you know what was going on with an array from MMC, etc. etc. With Dell you have a propietary MMC snap-in which is a pain in the ass to keep straight depending on the particular PERC flavor you're using and firmware revision of your card. *nix or BSD support? A shitty CLI or nothing. Or maybe a web management tool (WTF?) There is no standard for this sort of thing and it pisses me off to no end. Hell, there's a fucking standard for removable drive enclosures, but not for offloaded RAID volumes.
2) Shitty firmware / embedded system design I've been burned one too many times by firmware bugs and NVRAM failures.
3) Propietary on disk layout * No way to swap drives between systems with different RAID engines * Have to prepare unlabeled disks in BIOS/firmware tool before it can be used * Boot floppies for OS installs onto array. God, what is this, 1992?
The only RAID offload I ever use is complete offload. Seperate NAS/SAN devices with an embedded OS that present the volumes as LUNs or network shares. I've found these to be engineered to a much higher tolerances and you can always connect a TTY to it or SSH in and figure out what's going on with it.
Other than that we completely standardize on software RAID. CPU performance these days is sufficient enough that RAID-5 isn't a particularly notable hit. We'll actually buy 3WARE 95xx cards, and put in 12 JBOD disks just so we can have hotswap.:-/ It's really nice to be able to pull a subset of disks set up for softraid in Linux, and plug it into any old machine and have it magically appear.
Could you recover from having the wrong superblock on your filesystem? That's right. My SCSI enclosure somehow managed to write the wrong superblock across two LUNs (swapped). On reboot a fsck occured and proceeded to fuck everything up. Using some perl and header files for the superblock and inode formats, I was able to revert the changes and repair the damage. ext2 is simple enough that I did it and it wasn't too difficult. I don't know how much luck I'd have low-level manipulating reiserfs (I guess you have to be in the situation to go through it, otherwise you wouldn't bother). But yeah, since then I've felt more than confident leaving everything as ext3 since it has such wide use and a predictable behavior (at least to me).
Absent any pending interrupts, a task will run to completition in the same time it would take with or without interrupts enabled. So, having support for hard realtime scheduling (when you know in advance why you are doing it) is not an impediment to getting things done quickly. The ratio of 5 minutes to one hour in your solitare example is hyperbolic and unrealisitic. With a modern system (one that could run FreeDOS) with a scheduling granularity of even something as extreme as 100us you would experience a degradation of about 5-10% with clock-tick handling overhead on a 1-2GHZ CPU.
But in the case of a single main idle task (something suitable for FreeDOS loader + some memory/kernel/tasklet code) you probably don't care about a periodic timer interrupt. You probably care about lower frequency or OOB type stuff (video retrace, sound card, keyboard, network card, etc.). If you do use the timer interrupt it's for one-shot type stuff... set and call me later type things. I mean, the need for a task to "Go Fast" in this kind of environment is because you're threading calculations into a polling loop, or trying to fit them in between the receipt of one interrupt and needing them to be done and acted upon before the next. But you've got an environment that lets you handle interrupts switfly or on your own time... however you want to. So there's no need to disable interrupts and do things since you've got a fast, task-switchin', interrupt handlin' kernel that can do some of that for you. You make the decisions about what to handle and not handle, and when, at run time.
The benefit you gain is logical, code-level seperation between interrupt context code and the primary execution stream. And no need to poll to do I/O.
...a realtime kernel library you can link into your code. Most "high-performance" programs you write in full-on flat mode do this anyway. They either coordinate via the timer, vertical retrace, or hard drive/sound card DMA fill-request interrupt. And then they run a set of "tasks", that is, a bunch of potentially unrelated functions, in order, then return to the main busy loop.
So why not a small, RT kernel that lets you structure you program into seperate modules? It might provide you with some nice memory/syncro primitives that you can leverage. You can probably fit the text for a feature complete implementation with threads, round-robin and hard deadlines in 32K. In this fashion you can potentially "schedule" a bunch of DMA requests, and then collect the "results" out of order. This gives you a bit more flexibility in your coding without having to roll up your own state machine and stuff.
So, uh. What the fuck does VS have to do with anything? I've never used it so I can't comment. So it has variable-width fonts and logical indenting and spacing? Good for them. If it appears in anything _besides_ Visual Studio I'll be a happy camper.
A few PowerPC processors, and some FPGAs. Shouldn't cost much more than a typical hardware RAID SATA controller.
It could run a virtual FS in microcode on partitions on the disk (in addition to giving you standard RAID access to the deices). You use a slightly abstracted API to talk to it. Just throw your files into it, and it versions them, extracts text strings, etc. all on its' own. Then you can do fast search and retrieval of said content.
Man that would be cool. Google in your desktop. Google in your file servers.
Well, I wouldn't call it "Google". But like, GoogleVault. Or some kinda cool brandname like that. I'd be totally into it.
IIRC it's all Northup Grummond now. And they in turn outsource the production of their computing resources to other vendors (Cray, Sun, Supermicro, etc.)
I think it's a bit of wising up on their part. Why should they be so suspicious of what are now anonymous, commodity products? Just get it while the getting's good, you know? Better to stay simple and low profile than high profile and complicated that just screams "Government Purhcase! Government Purchase!"
Netezza has already been doing exactly this in their product line. They use FPGAs on each compute blade that handle disk access but also handle database record layout, and can do where clauses and projection while streaming from disk. See: http://en.wikipedia.org/wiki/Netezza
I also believe that intelligent disk IO will be important in the future. No, it's important right now. Disks are a bottleneck and having dedicated hardware that can leverage spindle parallelism and free up the memory disk controller pathway is very important.
I mean, the same could be said for, let's say, PageMaker. Or OpenOffice. Or a lot of text layout tools.
But code editors they are not.
We brough content folding and syntax highlighting to text editors. Now it's an appropriate time to bring them layout magic, I suppose.
If you mount it as ext2...
on
EXT4 Is Coming
·
· Score: 1
...then you don't need the journal. The journal is only of any concern when you don't cleanly unmount. That's it. ext2 won't mount unless the filesystem is marked clean, so you would have already suffered a fsck scan anyway, as opposed to a fast journal resync if it was ext3. BTW, ext3 just "starts from the beginning" at each mount. There's nothing to keep in sync.
Yeah, ext3 is great. I've recovered from _very bad_ situations involving hardware that might not have been possible with any other FS.
Yes. And that it's just misdirection. They've still got the media attention. They're being "hacked". Oh boo hoo (right). The Casino Royale trailers aren't out yet. I wouldn't be surprised if they show up on eon8 before http://www.apple.com/trailers/ or whatever.
It's some Viral Marketing group associated with MGM. Chris is a paid misinformant who will do anything to keep everyone interested for when the news breaks "for real". There used to be links on YTMND and Wikipedia but I can't find them anymore since "Chris" came out; everyone's jumping on the "it was a social experiment" bandwagon. Anyone have old links? There used to be a thread on 4chan, shoulda FUKKEN SAVED it.
None of them new though, but well integrated and there by default.
1) An automatic media playback/manipulation framework. Nothing new here (see DirectShow, gstreamer, Quicktime) but it's more transparent, easier to configure they way you want to, it's an OS-level service, and it comes with lots of filters and encoders/decoders out of the box.
2) SQL metabase for your files. Very similar to WinFS or beagle/inotify in style. You write plugins to extract metadata and it indexes it when you make FS changes. And standard widgets to search/query for file dialogs, file browser, etc. Which is important...
3) A decent security context system that seems to be a blend between NT's model and SELinux's model. It uses the ideas of contexts for users, files and processes from SELinux, but it doesn't burden you with complex transformation rules (instead you have trusted right sources (typically the logon manager), inheritance and voluntary dropping of rights). It offers far more numerous rights than NT or SELinux, and you can add your own.
Files and directories can carry security context identifiers, and the system matches them from the least to most specific user identifier that matches for allow or deny (all users, group member, specific user). The default for filesystems that support security contexts is deny, for those that don't (IE VFAT on flash drives), the default is allow.
Again, you can find examples of all of this implemented elsewhere. These guys are trying to take a lot of good ideas and put them all together in a single baseline that is relatively easy to operate and get your head around. Which I have to support.
Would I buy it? Probably not. Not enough hardware support to bother with a new OS. Better to add these features to existing ones.
Slashdot Mirror
...you suck at scripting.
...
Typical shell scripting idioms like:
for $each in *glob.pattern* ; do
command "$each"
mv "$each" "$(echo \"$each\" | sed -e s/stuff/replace)"
done
The only extra quoting necessary is in commands with variable substitution. And (while it may seem confusing), that syntax works even when the filenames have quotes internally. The double quotes identifies the contents to be treated as a single token with interpolation to be performed before passing on to ``command'', which is what you wanted.
Also the $() syntax is your friend. But remember to give it ""s too, you don't want it to expand it AND THEN tokenize it.
I'm not a DBA by any stretch.
:-/ Excuse me for being picky about package selection!
Yet I've gotten Oracle 9i and 10g humming quite nicely on RHEL3 and 4 (WS mind you), Fedora, and SLES 8 (United Linux). On x86 and x86_64. 9iR2 on RHEL 3 was a bit of a pain in the ass on AMD64 during install time, but once you got over a few humps you didn't have to worry about it again.
Solaris installs usually went smoother, but woe unto thee who neglected to install 32-bit userland packages on a 64-bit install.
RHEL is huge. Really, massively fucking huge.
It encompasses about 4 times as much stuff as you'd see in a Solaris install, and it supports a much wider range of hardware.
Red Hat should change their support contract structure.
Tier 1: Security updates and access to beta patches
Tier 2: Customer support for the following packages:
* The Kernel (hardware/stability issues)
* Bugs in RH-written tools (Anaconda, Kudzu, system-config-*, rhgb, etc.)
* Bugs in RH-modified packages relating to basic system services (firstboot, sysvinit, auditing, etc.)
Tier 3: Everything in Tier 2 + packages in "Base System", Dev Tools, Net Servers, and the Red Hat-branded packages (Postgres, JBoss, ClusterFS, etc.)
Tier 4: Everything in Tier 3 + the rest of the distro (mostly user-land stuff)
Most businesses only really need Tier 1 or 2. They probably have their own ideas about everything else they want to run (Oracle, MySQL, SAP, whatever). And anything beyond Tier 2 is really outside a lot of what the RH developers focus on, so the support is going to be shitty anyway).
By offering Tier 3 at the current offering price, Tier 4 at an increased price, and Tier 2 somewhere in between the current supported and un-supported rates, I think Red Hat could improve their responsiveness and be able to hire more people to improve support's response time.
As it is, their support is probably tied up in bugs relating to some included packages that aren't "core" but they have to support anyway by the virtue of including them. Such a tiering structure could make better use of support resources.
The real problem with Red-Hat is the legacy of its package management system; that turd's been polished so hard that you can see your face in it, but nevertheless remains a turd.
RPM is hardly legacy. It's pretty damn feature-complete. Care to explain what the issue with it is?
I always liked that kinda construction, and it goes back to days of oldskool hip hop.
So you take that components of your mash-ups and title it, you know:
Mario vs. London Philharmonic or whatever you've got going on in your track.
Unfortunately saying: "I like to compose Vs. (versus)" sounds kinda like verses or "I like to write lyrics".
I think if you avoid certain verbs before "versus" (drop, write, compose), and stick to more descriptive ones (track, mix, splice).
Shit, I like that last one.
"I really enjoy splicin' versus."
HTX based _anything_ some day.
That being said, that means every device would have to have carry a PCI bus emulation layer with it.
OS's don't know how to negotiate resources unless it looks like its connected on a well-known logical bus.
Unless you've got some magic "platform" driver that probe-detects it and works without resource allocation (you'd have to negotiate your IRQ for OOB notification through some OS-negotiated process... Hello PnP!)
That's big-E Enterprise.
I'm talking about sub-1m yearly IT budgets here *eye roll*.
"fell on" is a verb construction that demands an object (satellite-framed verb). You can't omit the object of the preposition in that case.
"reading" is a verb that implies an object (text, books). Therefore the pronoun is implied (book mentioned earlier in the sentence).
It's slow to write
Only if you allow partial writes (make sure you use a correctly configured filesystem). Okay so it's still N% slower, but you've got caching and you'll probably hit the limit of your bus first anyway.
if you lose a disk then read performance is significantly degraded until you get another
Always have spare disks. I like to use the baker's dozen rule... for every 12 you buy, get a 13th.
rebuilding is slow
True. But modern systems (software RAID) let you tune the rebuild performance.
Also, you should consider the following:
If you get a failed disk in a RAID (any RAID), the next thing you should do BEFORE a rebuild is to MAKE A BACKUP.
Because a rebuild is write-intensive and could trigger further failures if you're having disk remapping issues on your drives.
and if you get an unreadable sector during rebuilding you'll probably lose your entire array.
For this reason (and the clustered failure scenario mentioned above) you want to use drives that have functioning SMART implementation and that you know do internal sector remapping. Do research on your drives before you buy them. And replace disks as before they reach the 50% mark on remapped data.
Even 1gbps is a whole fucking lot of sustained disk traffic.
The example is hyperbolic.
You're better off using multiple RAID5s instead one large one, or better yet, using JFS or something that understands stripe sizes so it doesn't cause unnecessary parity reads for partial writes.
RAID5 can cause extra bus traffic to and from the controller. You need to check to see if your bottleneck is the card itself when you like 8+ drives attached.
It helps if you have more than one controller on seperate busses and you can stripe across them RAID50-style.
(Recommended on Opteron based systems with multiple CPUs and MCPs)
We run very "enterprise" setups where I work and you're right, it's "enterprisey" to go full on hardware RAID.
:-/
And deal with all the headaches that leads to:
1) Poor OS integration
** 3Ware
** Dell PERC
** Adaptec
need I go on?
You get alarms coming from inside the unit and you have no idea what the fuck is going on until you reboot and drop into the BIOS.
It's only recently that 3Ware started shipping a WBEM data source that could let you know what was going on with an array from MMC, etc. etc.
With Dell you have a propietary MMC snap-in which is a pain in the ass to keep straight depending on the particular PERC flavor you're using and firmware revision of your card.
*nix or BSD support? A shitty CLI or nothing. Or maybe a web management tool (WTF?)
There is no standard for this sort of thing and it pisses me off to no end. Hell, there's a fucking standard for removable drive enclosures, but not for offloaded RAID volumes.
2) Shitty firmware / embedded system design
I've been burned one too many times by firmware bugs and NVRAM failures.
3) Propietary on disk layout
* No way to swap drives between systems with different RAID engines
* Have to prepare unlabeled disks in BIOS/firmware tool before it can be used
* Boot floppies for OS installs onto array. God, what is this, 1992?
The only RAID offload I ever use is complete offload. Seperate NAS/SAN devices with an embedded OS that present the volumes as LUNs or network shares. I've found these to be engineered to a much higher tolerances and you can always connect a TTY to it or SSH in and figure out what's going on with it.
Other than that we completely standardize on software RAID. CPU performance these days is sufficient enough that RAID-5 isn't a particularly notable hit. We'll actually buy 3WARE 95xx cards, and put in 12 JBOD disks just so we can have hotswap.
It's really nice to be able to pull a subset of disks set up for softraid in Linux, and plug it into any old machine and have it magically appear.
So yeah, software RAID is your friend.
Could you recover from having the wrong superblock on your filesystem?
That's right. My SCSI enclosure somehow managed to write the wrong superblock across two LUNs (swapped). On reboot a fsck occured and proceeded to fuck everything up.
Using some perl and header files for the superblock and inode formats, I was able to revert the changes and repair the damage.
ext2 is simple enough that I did it and it wasn't too difficult. I don't know how much luck I'd have low-level manipulating reiserfs (I guess you have to be in the situation to go through it, otherwise you wouldn't bother).
But yeah, since then I've felt more than confident leaving everything as ext3 since it has such wide use and a predictable behavior (at least to me).
Absent any pending interrupts, a task will run to completition in the same time it would take with or without interrupts enabled.
So, having support for hard realtime scheduling (when you know in advance why you are doing it) is not an impediment to getting things done quickly. The ratio of 5 minutes to one hour in your solitare example is hyperbolic and unrealisitic. With a modern system (one that could run FreeDOS) with a scheduling granularity of even something as extreme as 100us you would experience a degradation of about 5-10% with clock-tick handling overhead on a 1-2GHZ CPU.
But in the case of a single main idle task (something suitable for FreeDOS loader + some memory/kernel/tasklet code) you probably don't care about a periodic timer interrupt. You probably care about lower frequency or OOB type stuff (video retrace, sound card, keyboard, network card, etc.). If you do use the timer interrupt it's for one-shot type stuff... set and call me later type things.
I mean, the need for a task to "Go Fast" in this kind of environment is because you're threading calculations into a polling loop, or trying to fit them in between the receipt of one interrupt and needing them to be done and acted upon before the next. But you've got an environment that lets you handle interrupts switfly or on your own time... however you want to. So there's no need to disable interrupts and do things since you've got a fast, task-switchin', interrupt handlin' kernel that can do some of that for you. You make the decisions about what to handle and not handle, and when, at run time.
The benefit you gain is logical, code-level seperation between interrupt context code and the primary execution stream. And no need to poll to do I/O.
...a realtime kernel library you can link into your code.
Most "high-performance" programs you write in full-on flat mode do this anyway. They either coordinate via the timer, vertical retrace, or hard drive/sound card DMA fill-request interrupt. And then they run a set of "tasks", that is, a bunch of potentially unrelated functions, in order, then return to the main busy loop.
So why not a small, RT kernel that lets you structure you program into seperate modules? It might provide you with some nice memory/syncro primitives that you can leverage. You can probably fit the text for a feature complete implementation with threads, round-robin and hard deadlines in 32K.
In this fashion you can potentially "schedule" a bunch of DMA requests, and then collect the "results" out of order. This gives you a bit more flexibility in your coding without having to roll up your own state machine and stuff.
La Blue Girl _does_ have an intersting plot.
And Blue Seed.
The rest of it is pretty much crap when it comes to anything involving tentacles and/or demons.
So, uh. What the fuck does VS have to do with anything?
I've never used it so I can't comment. So it has variable-width fonts and logical indenting and spacing? Good for them.
If it appears in anything _besides_ Visual Studio I'll be a happy camper.
... that talks to your secondary storage.
A few PowerPC processors, and some FPGAs. Shouldn't cost much more than a typical hardware RAID SATA controller.
It could run a virtual FS in microcode on partitions on the disk (in addition to giving you standard RAID access to the deices). You use a slightly abstracted API to talk to it. Just throw your files into it, and it versions them, extracts text strings, etc. all on its' own. Then you can do fast search and retrieval of said content.
Man that would be cool. Google in your desktop. Google in your file servers.
Well, I wouldn't call it "Google". But like, GoogleVault. Or some kinda cool brandname like that. I'd be totally into it.
IIRC it's all Northup Grummond now.
And they in turn outsource the production of their computing resources to other vendors (Cray, Sun, Supermicro, etc.)
I think it's a bit of wising up on their part. Why should they be so suspicious of what are now anonymous, commodity products? Just get it while the getting's good, you know? Better to stay simple and low profile than high profile and complicated that just screams "Government Purhcase! Government Purchase!"
Netezza has already been doing exactly this in their product line. They use FPGAs on each compute blade that handle disk access but also handle database record layout, and can do where clauses and projection while streaming from disk.
See: http://en.wikipedia.org/wiki/Netezza
I also believe that intelligent disk IO will be important in the future. No, it's important right now. Disks are a bottleneck and having dedicated hardware that can leverage spindle parallelism and free up the memory disk controller pathway is very important.
I mean, the same could be said for, let's say, PageMaker. Or OpenOffice. Or a lot of text layout tools.
But code editors they are not.
We brough content folding and syntax highlighting to text editors. Now it's an appropriate time to bring them layout magic, I suppose.
...then you don't need the journal. The journal is only of any concern when you don't cleanly unmount. That's it.
ext2 won't mount unless the filesystem is marked clean, so you would have already suffered a fsck scan anyway, as opposed to a fast journal resync if it was ext3.
BTW, ext3 just "starts from the beginning" at each mount. There's nothing to keep in sync.
Yeah, ext3 is great. I've recovered from _very bad_ situations involving hardware that might not have been possible with any other FS.
Yes. And that it's just misdirection.
They've still got the media attention. They're being "hacked". Oh boo hoo (right).
The Casino Royale trailers aren't out yet. I wouldn't be surprised if they show up on eon8 before http://www.apple.com/trailers/ or whatever.
It's some Viral Marketing group associated with MGM. Chris is a paid misinformant who will do anything to keep everyone interested for when the news breaks "for real".
There used to be links on YTMND and Wikipedia but I can't find them anymore since "Chris" came out; everyone's jumping on the "it was a social experiment" bandwagon. Anyone have old links? There used to be a thread on 4chan, shoulda FUKKEN SAVED it.
None of them new though, but well integrated and there by default.
1) An automatic media playback/manipulation framework. Nothing new here (see DirectShow, gstreamer, Quicktime) but it's more transparent, easier to configure they way you want to, it's an OS-level service, and it comes with lots of filters and encoders/decoders out of the box.
2) SQL metabase for your files. Very similar to WinFS or beagle/inotify in style. You write plugins to extract metadata and it indexes it when you make FS changes. And standard widgets to search/query for file dialogs, file browser, etc. Which is important...
3) A decent security context system that seems to be a blend between NT's model and SELinux's model. It uses the ideas of contexts for users, files and processes from SELinux, but it doesn't burden you with complex transformation rules (instead you have trusted right sources (typically the logon manager), inheritance and voluntary dropping of rights). It offers far more numerous rights than NT or SELinux, and you can add your own.
Files and directories can carry security context identifiers, and the system matches them from the least to most specific user identifier that matches for allow or deny (all users, group member, specific user). The default for filesystems that support security contexts is deny, for those that don't (IE VFAT on flash drives), the default is allow.
Again, you can find examples of all of this implemented elsewhere. These guys are trying to take a lot of good ideas and put them all together in a single baseline that is relatively easy to operate and get your head around. Which I have to support.
Would I buy it? Probably not. Not enough hardware support to bother with a new OS. Better to add these features to existing ones.