When you use parentheses in the middle of a sentence, it is customary to place them so that the sentence would still make sense
with the parenthetical content removed.
Alas, no, it is not customary, any more than using "lose" (with one O) to mean the opposite of "find" is customary. Commas in particular are quite often misplaced in this manner. Annoys the crap out of me.
(I suspect instead of "customary" you meant "grammatically correct".)
If they plan Linux support, why exactly is it called the "WiNRADiO"
Probably by association to Winmodems, which are cheaper to manufacture than real modems because most of the signal processing is offloaded to software (as someone once said, "using a $200 CPU to emulate a $7 UART").
From the blurb (no I didn't read the article!), it sounds like they are not only doing the same thing here, but they are actually proud of it and consider this to be a bullet-point feature.
So, according to the title of this article, Intel is actually still doing R & D work with their Pentium core? Guess the whole P6 line (PPro through P4 Xeon) didn't work out after all.
Inquiring minds want to know. Is it the original Pentium or the Pentium MMX? And did they ever fix the F00F bug?
Modern processors have loads of extensions, MMX, SIMD (Single Instruction, Multiple Data) which means that even if you overclocked
your old 8088 to 4.7 GHZ (hehe...would LOVE to see the fan required for that!!!) it would still run many orders of magnitude
slower.
Not so fast (no pun intended). Work done per clock has increased - thanks to pipelining we now have throughput of about one insn per hertz - but memory access times are a lot worse than they were back then. Fetching from L2 cache is a lot slower, per hertz, than fetching from main memory was back in the 4.77 MHz days. Even taking into account the 8088's 8-bit memory bus. Which bus didn't have to deal with moving page tables around, since the 8088 didn't have protected mode (not to be confused with Palladium, which it also didn't have).
The belief that relative memory access speeds don't matter is the Other Megahertz Myth.
Re:Only 7 ammendments left in the Bill of Rights
on
That Link Is Illegal
·
· Score: 1
Apples and oranges. Pro-Lifers assault, bomb and muderer people at abortion clinics.
Speaking of apples and oranges, most pro-lifers do not assault, bomb or murder people at abortion clinics. By "most" I mean at least three or four nines. Analogy: "Union members assault, bomb and murder those who cross picket lines." Or how about, "Palestinians assault, bomb and murder people in restaurants."
In any case, it's not as though buffer zones exist to prevent bombings. They exist because in public policy, the business interests of abortion mills - and the queasiness of the public stomach - are judged to be more important than the right of those with an unsavory message to peaceably assemble.
Go back to striking unions. Is it, or should it be, illegal for striking workers to picket a place of business? Should picketers be restricted to marching at least 100 feet away from said business even if 95 feet of that are public property? Bear in mind that the amount of "harrassment" one would experience crossing a picket line full of people shouting and waving signs is quite comparable to what a pair of customers would experience entering an abortion mill.
I think you and public policy makers are easily confused by the distinction between "Thou shalt not block or harrass customers" and "Thou shalt not wave thy sign within 50 feet of this door." If you think those two statements are equally reasonable, then you and I have fundamental differences in the philosophy of what constitutes a free society.
Any word on when this will be 'production worthy'?
No, the first I heard of it was as I was poking around a Red Hat ftp archive looking for some RPMs for chasing a bug reported by a RH user (turns out he was using an old version of my package, but I digress...) and I noticed the prelink package sitting there somewhere. It sounded a lot like the IRIX thing - and I've thought off and on over the years that it would be nice for Linux to have that - so I read the README.
Gooogle for "jakub jelinek prelink" - it'll tell you a lot more than I can.
Also, do you know of a website that has any performance numbers or
other details?
Thanks to Google we have his original announcement, where he claims to have reduced the startup overhead in Konqueror (before opening its first X window) from 0.510 seconds to 0.011 seconds. Of course this is a best-case scenario, as prelinking will be the most noticeable for big binaries with lots of shared library dependencies.
No you will see a pid per thread because, that is how the scheduler knows to schedule things.
Indeed we have not got rid of the concept of one pid per thread. But we do have an additional number, the thread group ID. The tgid corresponds to the pid of the thread group leader, and this is what will be returned by getpid() in the new pthreads. (What we call a pid is, and has always been, actually a thread ID.) This is exposed to/proc via a field in/proc/{tid}/status - one need only hack the procps utilities to make something useful of this.
An interesting question came up on l-k recently: how to maintain (efficiently) the uniqueness of a tgid. What if you are a thread group leader, you spawn off some threads, then you die, and eventually your pid is reused. Then another process could be a thread group leader with the same tgid as your thread group. If I remember correctly, the fix is simple and elegant: if the thread group leader dies before its "siblings", it sits around in a zombie state until they all die, all the while preventing reuse of its pid.
Just look when you see all
those proccesses with the same name, and see if they have the exact same memory usage. If they do it means they are using the same
memory and are threads.
Not necessarily. Try the following:
for x in 1 2 3 4 5; do sleep 60 & disown; done
ps ux | grep sleep
Notice how all five copies of 'sleep' have exactly the same name and memory usage, yet they are independent processes. If you really want to see evidence for threads, you need to check their tgids.
Re:if the protection is reasonable, where's the pr
on
DRM: How To Boil A Frog
·
· Score: 2, Insightful
Many pieces of software are already protected using a license manager or whatnot.
And a major headache this is, too, for me anyway. But I digress.
If all software was free, I would not be able to pursure my passion as a software
developer and still support myself.
I do. I wish I had more time to develop software, but I do manage to write a bit while supporting myself doing something else. (Perhaps if all the software my company bought were free, they could afford to pay me a little more and I could afford to spend a little more time on my software hobby.) But the main reason this argument doesn't fly is that most software development is actually not for the shrinkwrap market - it is writing custom software for individual customers. If all software were free, said customers would still be willing to pay for such work.
yet support things like the GPL that they probably
don't understand the full ramifications of. Every wonder why BSD is more stable?
Uh, I'm sorry to have to be the one to tell you this, but by uttering a complete non-sequitur I think you just shot whatever credibility you might have built up. Or do you have a grand unified theory that ties software stability to the use of various non-GPL licenses (some more free, some less) in various releases of BSD-derived software?
The analogy is directly applicable to music (I am also an amateur musician).
Amateur, meaning - you don't get paid for it. Yet you play music anyway. Funny. That's how I am with software.
If it
takes me 40 hours to develop a piece of software, I expect to get paid.
You have an unreasonable expectation, then. Whoever told you that mere effort guarantees remuneration fed you a line. That's not how markets work. You also have to succeed in producing something the market is willing to buy. If all of us go out and produce lots of free software and put you out of a job, you can hardly just sit and whinge about it.
But all that is beside the point. Traditional copyright law does not restrict the uses to which you may put your lawfully obtained material, except in context of other people. I.e. you can't put on public performances without negotiating royalties, or make copies to "share" with others, but anything you do for your own gratification has been allowed - including backup copies, etc. Now with DRM, The Man wants to retain control over how you use what you have lawfully obtained. This in itself is more or less fair play, and I'm happy with the Spy vs. Spy of creating / defeating playback protection - except that they've rigged the contest with the DMCA so we can't legally play at all.
Currently in Linux every thread is assigned a distinct process ID
Ah, but not any more. With the new NPTL, the getpid() call will return the same number for each thread in a process. I don't actually know how or if this perturbs the/proc data, though I expect it doesn't, meaning that the procps utilities will still have to be rewritten to properly portray the new abstractions.
One way possibly to speed up loading large apps is to staticly link 'em (icky!) and then do "cat app >/dev/null" before starting
it so it's in the disk cache first.
ELF runtime linking is inefficient and does unpleasant things to your COW pages. I haven't investigated this in full, but Jakub Jelinek of Red Hat has written a program to "pre-link" your ELF libraries and executables, so that you can mmap, sanity check, and go without any runtime relocation.
Not a new idea, actually - IRIX, I believe, solves the same problem in pretty much the same way. Digital Unix attempts to avoid it by maintaining a cache of "allocated" address ranges and letting the compile-time linker read and update said cache, in the hopes that no libraries' addresses will clash at runtime and thus no relocations would need to be made. But then, DU had the luxury of a 64-bit address space, so they could afford to "waste" it as it will never run out. (Please no jokes about 640k of address space being enough for anybody - except from people who actually understand how huge a 64-bit address space actually is.)
That said, you're still stuck with the CPU time the app takes to initialize and configure itself internally.
When does all this great stuff reach production? (To then be pre-packaged by RedHat, et. al.)
2.6 is supposed to feature-freeze on All Hallows' Eve, and there is enough buzz about this that it may actually happen on schedule. Expect a few months of shakedown before 2.6.0 gold, then (if they're smart) Red Hat will pound on it for a couple monts more, minimum, before selling it to the people to whom they promise a stable OS.
Then again, I guess it's possible that Red Hat, being the sponsor for this work, will backport it to their 2.4-based kernels and package it up for the enterprise. (*shudder* - Doesn't "enterprise" mean "business"? Why does it always, in the computing world, imply "big business"?)
There is no new threading model. The thread APIs are the same, so when you install the right kernel and glibc all apps will
benefit.
True, but note that if they just drop this stuff straight into glibc there could be some application incompatibilities. Ulrich Drepper explicitly mentions this: if your app relies on (read: works around) any of Linux's former deviations from the POSIX thread standard, it will break now that glibc pthreads are POSIX-compliant.
At the prospect of breaking ABI compatibility (something the glibc developers are loath to do - glibc 2.0 was supposed to be the last non-backward-compatible C library for Linux) - I imagine they will tread rather carefully when it comes to "transparently" replacing Linuxthreads with NPTL.
I was a bit disatisfied with this minimum, but I suppose I'll live with it now (or port to linux) if I have to, or
upgrade to a 64 bit os if it becomes a practical limit in the future.
One of the nice things about Linux. You don't have to live with any of these 32-bit limitations if your application is big enough to justify 64-bitness. While Microsoft had NT running on Alpha, I understand it was essentially still a 32-bit OS - it was only truly ported to 64 bits when Itanium support was added. Linux, on the other hand, has had true 64-bit implementations running since '94 or '95, so you can be fairly confident that the niggling little 32-bit-isms have mostly been caught by now.
Anyway, Charles Dickens used to stream his novels over snail mail. So did all of his contemporaries. It's called serial publication, and there's no reason you can't do it with media today.
Oh, it's clear now alright. More elitism, that's all it is. "Oh, we don't need a GUI installer..GUI installers are for NEWBIES!"
You think they couldn't have a GUI installer for the x86 platform, and leave the text-based installer on the other 10 platforms?
You didn't really understand a word he said, did you? Good thing you're posting anonymously, it would be a shame to make a fool out of yourself in public. In Debian, all architectures are equal. If a package doesn't compile, or has serious bugs, on only a specific architecture, that is a release-critical bug and can, if not dealt with, keep the package out of the next release - for all architectures. (Of course, some packages just don't make sense on some architectures - the X servers on S/390, for example. Those are the exceptions, though.)
So, given that philosophy, you think it is ok to spend a lot of effort polishing a GUI installer that only works on one or two architectures? Apparently the Debian developers don't think so. They are busy writing their own installer as we speak, and it does have a GUI frontend for people who need that sort of thing.
I know you aren't a Debian developer - they don't allow anonymous cowards - so you're not really in much position to complain about the work they do on their own time, NIH or not.
Speaking of which, what's the deal with GUI installers in the first place? Are there really people out there who will gauge the usefulness or merit of an OS distribution by whether or not they can use a mouse to click on pretty icons during a process which should only be necessary once in the life of the computer? (This ain't Windows 98, folks, no need to reinstall every 3 months.) Certainly it is not intended to make the installation process objectively easier or more flexible - nothing about a GUI is inherently necessary for this. Is it just the perception that users' minds are so calcified that they will immediately write off any interface not involving pictures and mice as "too hard" without actually seeing if this is so? Is it the desire to create a "slick" first impression instead of spending the same effort trying to improve aspects of the OS which will affect the user far more in the long run? Is it merely to cater to the habits of trade rag reviewers who are too lazy or pressed for time to actually try anything beyond the initial installation, so that their reviews effectively become a mere beauty contest for installation widgets?
*thwack* Oh, sorry, you caught me on a cynical day. (: Fortunately, you being an AC and all, it's not like I was actually flaming a real person.
Moderators: it's not flamebait, it's an actual flame. I suggest Offtopic.
Is there any FS/API that allows ACID style transactions for applications on filesystems?
Not to my knowledge, but you can get quite a bit of mileage out of the fact that mkdir() and rename() are guaranteed atomic. (rename() over an existing file is particularly useful.) Sprinkle in fsync() and file locking as needed.
I know this isn't what you really want - atomic updates of multiple files at once....
I studied XFS fairly extensively after I had to repair a disk that had 1 of its 23 heads fail. From the remaining 22/23rd of the
disk I managed to recover almost every file and directory, by writing my own XFS filesystem interpretation code. The on-disk
organization of the filesystem is fairly simple and straightforward, I can't imagine where the hundreds of K of code is going.
I've got two guesses. One, XFS has a lot of advanced features. For example, you can actually reserve disk bandwidth - assuming the disk goes a certain speed, XFS is prepared to guarantee your multimedia app that it can get a certain amount of data in or out per second. You can even have sub-partitions within your XFS partition, separated out so that only one sub-partition has guaranteed I/O rates. (I don't remember the details. It's all about multimedia, at any rate. (No pun intended.)) Then there are the more mundane features like ACLs and extended attributes.
Second, since XFS came from IRIX, I'm guessing the SGI engineers did what many people do when porting code from one system to another: reconstruct the original environment. I have no grounds for saying this - it's just a guess - but I can well imagine the SGI engineers deciding to port a lot of IRIX kernel functionality to the Linux kernel rather than adapt XFS to the native Linux way of doing things, which is a lot less featureful / bloated (pick your adjective).
I won't be shocked if the answer does lie in that kjournald daemon -- that XFS is bigger than ext3 because ext3 puts most of the
bloat into a user-mode daemon instead of the kernel.
Nope, kjournald is part of the kernel - it's not a separate user-space daemon. You see it in your 'ps' output because it is a kernel thread. As such, it is scheduled like a userspace process, even though it isn't running a userspace program and never drops into user mode. Any time the Linux kernel spawns a new kernel thread, it will show up in 'ps' output that way. They usually try to name threads starting with 'k' so as to tip you off. Unfortunately this is probably not very effective for those of you who use certain non-GNOME desktop environments....
Here's the basic theory. Think about what happens when you make a change on a filesystem - say you add a file to a directory. The system has to:
add a filename entry to the directory itself
allocate the initial blocks for the file, from the pool of free space in your filesystem
create the inode, which is a block of information about the file. The inode includes file modification times, owner, permissions, file type (regular file? directory? etc), and the location of its actual data blocks
if there are too many data blocks, allocate one or more "indirect blocks", which are extensions to the inode so it can hold more data blocks - inodes usually have a fixed size. Initialise these with the correct block numbers as well.
actually write the file contents to the data blocks you have allocated
If you don't do these things in the correct order, there will be times when the on-disk structure is not consistent. For example, you may have modified the directory to include an entry for the new file, but the entry points at an inode which hasn't been filled in yet. Or the inode may be filled in, but the free space pool hasn't been updated to correspond with the data block allocations in the inode. Throw in other modifications like deleting files or making them larger or smaller, and it gets pretty complicated. If the machine happens to crash at such a time - or the power goes out and you don't have a UPS - the disk will be in an inconsistent state. This has two major consequences:
the filesystem checker, or fsck (the equivalent Windows utility is scandisk) will have to run next time you boot, and go over the whole structure of your filesystem, which can take minutes or even hours on a large enough disk (80 GB takes a long time unless your disks are very fast). Nobody wants to sit around for 15 minutes waiting for the server to finish rebooting.
depending on exactly what was written to disk in what order, the fsck utility may not even be able to restore your filesystem to a consistent state at all, or it may lose important files or directories in the process of doing so.
Journalling prevents both problems (barring bugs in your OS or hardware, of course) by writing transactions to your filesystem. Instead of making changes directly to your directories, inodes, free block maps, etc, the filesystem batches up such changes by spooling them to a separate area on disk, the journal. Then, when it has written enough such changes to account for an entire, self-consistent transaction, it puts a marker in the journal indicating "transaction complete" and starts copying these changes to their usual locations on disk. Meanwhile, the next transaction can be spooled onto the end of the journal area, and it will get its own "transaction complete" marker when it is done. A journal can hold a lot of transactions - only limited by the journal size, which is usually configurable. When a transaction has been fully copied out of the journal to its final locations, it is re-labeled "journal free space" in the journal.
How does this help? Imagine that the machine goes down while a transaction is still incomplete in the journal. Next time you boot, the OS "replays" the journal: it looks for all the completed transactions and commits each part of a transaction to its correct permanent location. It ignores journal free space, and any incomplete transactions - essentially rewinding the filesystem state to the end of the last completed transaction. There is never any danger of "partially updated" filesystem state, since each transaction starts and ends with a known-consistent state.
(Ah, but what happens it the OS goes down again while replaying a journal? No big deal: next time it boots, it just replays the same journal again, which produces the same result as it would have done the first time.)
Some simplifications, obviously, but that's the basic idea. Did it help?
The different levels of journalling have to do with whether all filesystem data is journalled or only some of it. You usually only journal metadata, which is the filesystem structure: directories, inodes, free block maps, etc. That's because copying all your file contents twice (first into the journal, then into its permanent location in the filesystem) is quite slow. The main purpose of a journal is not to guarantee pristine file contents in the event of partially written files, but to ensure a consistent view of the filesystem as a whole - so you can avoid that long fsck and avoid ever ending up with a partially or fully scrambled filesystem (modulo hardware failure, of course).
Hell NTFS a la Win2k/XP is actually a very mature filesystem, I wouldn't have a problem running it instead of reiser or ext3.
On Linux? I would. The maturity of a filesystem implementation in NT 5 has no correlation to its maturity in Linux. For one thing, it is not based on the same codebase! (Imagine, Microsoft code in the Linux kernel? Actually, yes, but not in ntfs. One phantom mod point for the first poster to know where.) It is not written by the same people. It is not implemented to the same design docs. It is not even implemented to the same specs - the Linux implementation is entirely reverse-engineered.
The only thing in common between the NT 5 version of NTFS and the Linux version of NTFS is the on-disk layout. Which, by the way, isn't even very Unixy. Sure, it has hard links (unlike many legacy filesystems) but I don't think it has symlinks, named pipes, sockets, device specials, or u-g-o file permissions. I'm not sure whether it supports the mtime/atime/ctime tuple, but whatever timestamps it has are probably in 64-bit nanoseconds rather than 32-bit seconds. I think each file object only has a single owner (no "group"), and said owner is expressed as a SID object (128+ bits), rather than a simple 16- or 32-bit integer. Filenames are expressed in little-endian UCS-2 or some such, rather than ASCII or UTF-n. NTFS even supports optional (hey, at least they're optional!) "short filenames" to be DOS-software-compliant, just like VFAT.
Which all goes to say that if/when Linux gets mature NTFS support, the filesystem code will go through a rather complex translation process from on-disk layout to in-core data structures (and vice versa), which cannot be made as efficient as a filesystem designed with Unix semantics in mind. Using NTFS in Linux for anything other than migration, or dual-booting your legacy systems, will never make sense.
We also need good user-mode utils to convert from one to another, resize/split/merge partitions
Agreed. Support in the various fdisk utils for MS Dynamic Disks would be a good start....
Slashdot Mirror
Heh.
Let them get back to basics. Write their own songs, play their own instruments.
Alas, no, it is not customary, any more than using "lose" (with one O) to mean the opposite of "find" is customary. Commas in particular are quite often misplaced in this manner. Annoys the crap out of me.
(I suspect instead of "customary" you meant "grammatically correct".)
Probably by association to Winmodems, which are cheaper to manufacture than real modems because most of the signal processing is offloaded to software (as someone once said, "using a $200 CPU to emulate a $7 UART").
From the blurb (no I didn't read the article!), it sounds like they are not only doing the same thing here, but they are actually proud of it and consider this to be a bullet-point feature.
People will still be using PowerPoint ten years from now? Now you've got me all depressed.
So, according to the title of this article, Intel is actually still doing R & D work with their Pentium core? Guess the whole P6 line (PPro through P4 Xeon) didn't work out after all.
Inquiring minds want to know. Is it the original Pentium or the Pentium MMX? And did they ever fix the F00F bug?
Not so fast (no pun intended). Work done per clock has increased - thanks to pipelining we now have throughput of about one insn per hertz - but memory access times are a lot worse than they were back then. Fetching from L2 cache is a lot slower, per hertz, than fetching from main memory was back in the 4.77 MHz days. Even taking into account the 8088's 8-bit memory bus. Which bus didn't have to deal with moving page tables around, since the 8088 didn't have protected mode (not to be confused with Palladium, which it also didn't have).
The belief that relative memory access speeds don't matter is the Other Megahertz Myth.
Speaking of apples and oranges, most pro-lifers do not assault, bomb or murder people at abortion clinics. By "most" I mean at least three or four nines. Analogy: "Union members assault, bomb and murder those who cross picket lines." Or how about, "Palestinians assault, bomb and murder people in restaurants."
In any case, it's not as though buffer zones exist to prevent bombings. They exist because in public policy, the business interests of abortion mills - and the queasiness of the public stomach - are judged to be more important than the right of those with an unsavory message to peaceably assemble.
Go back to striking unions. Is it, or should it be, illegal for striking workers to picket a place of business? Should picketers be restricted to marching at least 100 feet away from said business even if 95 feet of that are public property? Bear in mind that the amount of "harrassment" one would experience crossing a picket line full of people shouting and waving signs is quite comparable to what a pair of customers would experience entering an abortion mill.
I think you and public policy makers are easily confused by the distinction between "Thou shalt not block or harrass customers" and "Thou shalt not wave thy sign within 50 feet of this door." If you think those two statements are equally reasonable, then you and I have fundamental differences in the philosophy of what constitutes a free society.
Is that how you spell it? I always spell it Gooogle. (:
No, the first I heard of it was as I was poking around a Red Hat ftp archive looking for some RPMs for chasing a bug reported by a RH user (turns out he was using an old version of my package, but I digress...) and I noticed the prelink package sitting there somewhere. It sounded a lot like the IRIX thing - and I've thought off and on over the years that it would be nice for Linux to have that - so I read the README.
Gooogle for "jakub jelinek prelink" - it'll tell you a lot more than I can.
Thanks to Google we have his original announcement, where he claims to have reduced the startup overhead in Konqueror (before opening its first X window) from 0.510 seconds to 0.011 seconds. Of course this is a best-case scenario, as prelinking will be the most noticeable for big binaries with lots of shared library dependencies.
Indeed we have not got rid of the concept of one pid per thread. But we do have an additional number, the thread group ID. The tgid corresponds to the pid of the thread group leader, and this is what will be returned by getpid() in the new pthreads. (What we call a pid is, and has always been, actually a thread ID.) This is exposed to /proc via a field in /proc/{tid}/status - one need only hack the procps utilities to make something useful of this.
An interesting question came up on l-k recently: how to maintain (efficiently) the uniqueness of a tgid. What if you are a thread group leader, you spawn off some threads, then you die, and eventually your pid is reused. Then another process could be a thread group leader with the same tgid as your thread group. If I remember correctly, the fix is simple and elegant: if the thread group leader dies before its "siblings", it sits around in a zombie state until they all die, all the while preventing reuse of its pid.
Not necessarily. Try the following:
Notice how all five copies of 'sleep' have exactly the same name and memory usage, yet they are independent processes. If you really want to see evidence for threads, you need to check their tgids.
Aren't we all? (:
And a major headache this is, too, for me anyway. But I digress.
I do. I wish I had more time to develop software, but I do manage to write a bit while supporting myself doing something else. (Perhaps if all the software my company bought were free, they could afford to pay me a little more and I could afford to spend a little more time on my software hobby.) But the main reason this argument doesn't fly is that most software development is actually not for the shrinkwrap market - it is writing custom software for individual customers. If all software were free, said customers would still be willing to pay for such work.
Uh, I'm sorry to have to be the one to tell you this, but by uttering a complete non-sequitur I think you just shot whatever credibility you might have built up. Or do you have a grand unified theory that ties software stability to the use of various non-GPL licenses (some more free, some less) in various releases of BSD-derived software?
Amateur, meaning - you don't get paid for it. Yet you play music anyway. Funny. That's how I am with software.
You have an unreasonable expectation, then. Whoever told you that mere effort guarantees remuneration fed you a line. That's not how markets work. You also have to succeed in producing something the market is willing to buy. If all of us go out and produce lots of free software and put you out of a job, you can hardly just sit and whinge about it.
But all that is beside the point. Traditional copyright law does not restrict the uses to which you may put your lawfully obtained material, except in context of other people. I.e. you can't put on public performances without negotiating royalties, or make copies to "share" with others, but anything you do for your own gratification has been allowed - including backup copies, etc. Now with DRM, The Man wants to retain control over how you use what you have lawfully obtained. This in itself is more or less fair play, and I'm happy with the Spy vs. Spy of creating / defeating playback protection - except that they've rigged the contest with the DMCA so we can't legally play at all.
Ah, but not any more. With the new NPTL, the getpid() call will return the same number for each thread in a process. I don't actually know how or if this perturbs the /proc data, though I expect it doesn't, meaning that the procps utilities will still have to be rewritten to properly portray the new abstractions.
ELF runtime linking is inefficient and does unpleasant things to your COW pages. I haven't investigated this in full, but Jakub Jelinek of Red Hat has written a program to "pre-link" your ELF libraries and executables, so that you can mmap, sanity check, and go without any runtime relocation.
Not a new idea, actually - IRIX, I believe, solves the same problem in pretty much the same way. Digital Unix attempts to avoid it by maintaining a cache of "allocated" address ranges and letting the compile-time linker read and update said cache, in the hopes that no libraries' addresses will clash at runtime and thus no relocations would need to be made. But then, DU had the luxury of a 64-bit address space, so they could afford to "waste" it as it will never run out. (Please no jokes about 640k of address space being enough for anybody - except from people who actually understand how huge a 64-bit address space actually is.)
That's what the Emacs unexec solution is for!
2.6 is supposed to feature-freeze on All Hallows' Eve, and there is enough buzz about this that it may actually happen on schedule. Expect a few months of shakedown before 2.6.0 gold, then (if they're smart) Red Hat will pound on it for a couple monts more, minimum, before selling it to the people to whom they promise a stable OS.
Then again, I guess it's possible that Red Hat, being the sponsor for this work, will backport it to their 2.4-based kernels and package it up for the enterprise. (*shudder* - Doesn't "enterprise" mean "business"? Why does it always, in the computing world, imply "big business"?)
True, but note that if they just drop this stuff straight into glibc there could be some application incompatibilities. Ulrich Drepper explicitly mentions this: if your app relies on (read: works around) any of Linux's former deviations from the POSIX thread standard, it will break now that glibc pthreads are POSIX-compliant.
At the prospect of breaking ABI compatibility (something the glibc developers are loath to do - glibc 2.0 was supposed to be the last non-backward-compatible C library for Linux) - I imagine they will tread rather carefully when it comes to "transparently" replacing Linuxthreads with NPTL.
One of the nice things about Linux. You don't have to live with any of these 32-bit limitations if your application is big enough to justify 64-bitness. While Microsoft had NT running on Alpha, I understand it was essentially still a 32-bit OS - it was only truly ported to 64 bits when Itanium support was added. Linux, on the other hand, has had true 64-bit implementations running since '94 or '95, so you can be fairly confident that the niggling little 32-bit-isms have mostly been caught by now.
Linus raised some valid objections, Ingo reworked some of the code, and it's all in 2.5.36. No worries.
Did you click on the "few extra features" bit? It's the funniest l-k post I've seen in some time. That whole sub-thread (sorry) was pretty good.
And you can't demoronise your posts. (:
Anyway, Charles Dickens used to stream his novels over snail mail. So did all of his contemporaries. It's called serial publication, and there's no reason you can't do it with media today.
You didn't really understand a word he said, did you? Good thing you're posting anonymously, it would be a shame to make a fool out of yourself in public. In Debian, all architectures are equal. If a package doesn't compile, or has serious bugs, on only a specific architecture, that is a release-critical bug and can, if not dealt with, keep the package out of the next release - for all architectures. (Of course, some packages just don't make sense on some architectures - the X servers on S/390, for example. Those are the exceptions, though.)
So, given that philosophy, you think it is ok to spend a lot of effort polishing a GUI installer that only works on one or two architectures? Apparently the Debian developers don't think so. They are busy writing their own installer as we speak, and it does have a GUI frontend for people who need that sort of thing.
I know you aren't a Debian developer - they don't allow anonymous cowards - so you're not really in much position to complain about the work they do on their own time, NIH or not.
Speaking of which, what's the deal with GUI installers in the first place? Are there really people out there who will gauge the usefulness or merit of an OS distribution by whether or not they can use a mouse to click on pretty icons during a process which should only be necessary once in the life of the computer? (This ain't Windows 98, folks, no need to reinstall every 3 months.) Certainly it is not intended to make the installation process objectively easier or more flexible - nothing about a GUI is inherently necessary for this. Is it just the perception that users' minds are so calcified that they will immediately write off any interface not involving pictures and mice as "too hard" without actually seeing if this is so? Is it the desire to create a "slick" first impression instead of spending the same effort trying to improve aspects of the OS which will affect the user far more in the long run? Is it merely to cater to the habits of trade rag reviewers who are too lazy or pressed for time to actually try anything beyond the initial installation, so that their reviews effectively become a mere beauty contest for installation widgets?
*thwack* Oh, sorry, you caught me on a cynical day. (: Fortunately, you being an AC and all, it's not like I was actually flaming a real person.
Moderators: it's not flamebait, it's an actual flame. I suggest Offtopic.
Not to my knowledge, but you can get quite a bit of mileage out of the fact that mkdir() and rename() are guaranteed atomic. (rename() over an existing file is particularly useful.) Sprinkle in fsync() and file locking as needed.
I know this isn't what you really want - atomic updates of multiple files at once....
I've got two guesses. One, XFS has a lot of advanced features. For example, you can actually reserve disk bandwidth - assuming the disk goes a certain speed, XFS is prepared to guarantee your multimedia app that it can get a certain amount of data in or out per second. You can even have sub-partitions within your XFS partition, separated out so that only one sub-partition has guaranteed I/O rates. (I don't remember the details. It's all about multimedia, at any rate. (No pun intended.)) Then there are the more mundane features like ACLs and extended attributes.
Second, since XFS came from IRIX, I'm guessing the SGI engineers did what many people do when porting code from one system to another: reconstruct the original environment. I have no grounds for saying this - it's just a guess - but I can well imagine the SGI engineers deciding to port a lot of IRIX kernel functionality to the Linux kernel rather than adapt XFS to the native Linux way of doing things, which is a lot less featureful / bloated (pick your adjective).
Nope, kjournald is part of the kernel - it's not a separate user-space daemon. You see it in your 'ps' output because it is a kernel thread. As such, it is scheduled like a userspace process, even though it isn't running a userspace program and never drops into user mode. Any time the Linux kernel spawns a new kernel thread, it will show up in 'ps' output that way. They usually try to name threads starting with 'k' so as to tip you off. Unfortunately this is probably not very effective for those of you who use certain non-GNOME desktop environments....
Here's the basic theory. Think about what happens when you make a change on a filesystem - say you add a file to a directory. The system has to:
If you don't do these things in the correct order, there will be times when the on-disk structure is not consistent. For example, you may have modified the directory to include an entry for the new file, but the entry points at an inode which hasn't been filled in yet. Or the inode may be filled in, but the free space pool hasn't been updated to correspond with the data block allocations in the inode. Throw in other modifications like deleting files or making them larger or smaller, and it gets pretty complicated. If the machine happens to crash at such a time - or the power goes out and you don't have a UPS - the disk will be in an inconsistent state. This has two major consequences:
Journalling prevents both problems (barring bugs in your OS or hardware, of course) by writing transactions to your filesystem. Instead of making changes directly to your directories, inodes, free block maps, etc, the filesystem batches up such changes by spooling them to a separate area on disk, the journal. Then, when it has written enough such changes to account for an entire, self-consistent transaction, it puts a marker in the journal indicating "transaction complete" and starts copying these changes to their usual locations on disk. Meanwhile, the next transaction can be spooled onto the end of the journal area, and it will get its own "transaction complete" marker when it is done. A journal can hold a lot of transactions - only limited by the journal size, which is usually configurable. When a transaction has been fully copied out of the journal to its final locations, it is re-labeled "journal free space" in the journal.
How does this help? Imagine that the machine goes down while a transaction is still incomplete in the journal. Next time you boot, the OS "replays" the journal: it looks for all the completed transactions and commits each part of a transaction to its correct permanent location. It ignores journal free space, and any incomplete transactions - essentially rewinding the filesystem state to the end of the last completed transaction. There is never any danger of "partially updated" filesystem state, since each transaction starts and ends with a known-consistent state.
(Ah, but what happens it the OS goes down again while replaying a journal? No big deal: next time it boots, it just replays the same journal again, which produces the same result as it would have done the first time.)
Some simplifications, obviously, but that's the basic idea. Did it help?
The different levels of journalling have to do with whether all filesystem data is journalled or only some of it. You usually only journal metadata, which is the filesystem structure: directories, inodes, free block maps, etc. That's because copying all your file contents twice (first into the journal, then into its permanent location in the filesystem) is quite slow. The main purpose of a journal is not to guarantee pristine file contents in the event of partially written files, but to ensure a consistent view of the filesystem as a whole - so you can avoid that long fsck and avoid ever ending up with a partially or fully scrambled filesystem (modulo hardware failure, of course).
HTH..
FWIW, so does IBM JFS. And ext2, Andreas's ext2online patch. Perhaps ext2online can be ported to ext3 some day..
On Linux? I would. The maturity of a filesystem implementation in NT 5 has no correlation to its maturity in Linux. For one thing, it is not based on the same codebase! (Imagine, Microsoft code in the Linux kernel? Actually, yes, but not in ntfs. One phantom mod point for the first poster to know where.) It is not written by the same people. It is not implemented to the same design docs. It is not even implemented to the same specs - the Linux implementation is entirely reverse-engineered.
The only thing in common between the NT 5 version of NTFS and the Linux version of NTFS is the on-disk layout. Which, by the way, isn't even very Unixy. Sure, it has hard links (unlike many legacy filesystems) but I don't think it has symlinks, named pipes, sockets, device specials, or u-g-o file permissions. I'm not sure whether it supports the mtime/atime/ctime tuple, but whatever timestamps it has are probably in 64-bit nanoseconds rather than 32-bit seconds. I think each file object only has a single owner (no "group"), and said owner is expressed as a SID object (128+ bits), rather than a simple 16- or 32-bit integer. Filenames are expressed in little-endian UCS-2 or some such, rather than ASCII or UTF-n. NTFS even supports optional (hey, at least they're optional!) "short filenames" to be DOS-software-compliant, just like VFAT.
Which all goes to say that if/when Linux gets mature NTFS support, the filesystem code will go through a rather complex translation process from on-disk layout to in-core data structures (and vice versa), which cannot be made as efficient as a filesystem designed with Unix semantics in mind. Using NTFS in Linux for anything other than migration, or dual-booting your legacy systems, will never make sense.
Agreed. Support in the various fdisk utils for MS Dynamic Disks would be a good start....