You cannot change the function to use UTF-8 internally without also changing all callers of this function. The same for database - you have to modify (or at least check whether they are doing anything encoding-sensitive such as a case conversions) all places which execute database queries. Sometimes incremental changes are simply not possible.
Sure, they are small changes, but it takes time to find all the places where the change is needed, and they are scattered all over the code base. And the move of the whole application (think web-based information system) to the new UTF-8 environment should be done atomically.
When averything you are doing in your branch are small (one-line) changes like this, you don't have a big problem a month later when you do the merge. Or you can incremenally merge the changesets from the trunk to your own branch (i.e. rebase), and then at the end merge your branch to the trunk.
There definitely _are_ cases when branching and merging huge branches make sense. One such example is one developer doing huge structural changes all-over the code base, while other developers continue doing their own work (e.g. development of new parts of code). Think changing a previously ASCII-only project to use UTF-8 internally. Or adding i18n support to all strings.
But there's no direct unicode support in the language -- if you're lucky, there are functions you can pipe it through.
3) They're just lists of numbers; they're neither ASCII nor Latin1. There is unicode parsing in the XMERL module.
Which is exactly the problem that GP discussed. There is a huge difference between a true in-language support of Unicode (such as the one in Perl) and just "the Unicode parsing library". In Perl there is a difference between "string of bytes" and "string of characters", and this distinction is made when the string is created (i.e. in the I/O layer when it is read from the file, or in the source code pragma when it is a literal constant). And then all things work as expected (conversion between upper and lower case, word boundaries, string length in bytes or in characters, etc.) - differently on a character string than on a byte string.
This means, that the only place you have to actually "handle" unicode is the point where the data enter your program or leave it. All the other things (libraries etc) just magically work without needing a change. This cannot be easily done without an in-language support (C or maybe Erlang).
Short form: The OSI should not be allowed to define what "Open Source" means any more than McDonalds should be allowed to define what "Hamburger" means. Remind me again since when McDonald's had a trademark on the word "Hamburger". OSI has a trademark on the term "Open Source", so naturally they are allowed to define what "Open Source" means.
I think there is no way to miss a rollback. Rollback is simply a transaction without commit. So when you create a FS snapshot with a transaction still in progress, then you will see partial transaction in the log, and maybe rows modified by a transaction which is not explicitly marked as commited, so when you restore from this backup and start the database engine, it will correctly detect it as an unfinished transaction and will not use its data.
The backup with transaction log _cannot_ be made more reliable (if it could, then the database would not be resistent to the host computer crash). It can be faster, easier to restore, etc. But more reliable? No way.
Well, backups over FS (block device, in fact) snapshot sound reasonable to me. After all, database has to be prepared to be in consistent state in case of a filesystem crash.
You may miss few commits just before the snapshot has been created, but in case the database does buffering, you will miss them anyway when/if machine crashes.
The point is that FS snapshot should give you a backup of the database in a consistent state, which is sufficient for most uses.
The OS & Applications simply don't see the difference between two real cores and a hyperthreading core. If I run another thread on a hyperthreading core, I'll slowdown the other thread.
Wrong. Linux scheduler can distinguish between two real cores and a hyperthreading core (i.e. it prefers to run the threads on independent cores). Linux scheduler can also take into consideration core to socket mapping (it prefers to run threads on cores in a single socket in order to allow the other sockets lower their frequency when idle).
Hyperthreading/SMT can hurt performance anyway, because of the bigger L1/L2 cache pressure.
I am eager to replace my current phone with Openmoko. However, I use a SIM Toolkit application for my banking. I wanted to look up whether Openmoko plans some STK support, but I have only found this post in gsmd-devel archives from March. Does anybody know what is the state of SIM Toolkit support in Openmoko?
I often need to read something from one window (an example in the manpage, maybe), and write without looking into another window. This is why auto-raising the focused window is plain wrong (it can obscure the window you want to read from) and this is why using the device from TFA for focus tracking would not be usable.
Maybe I'm just confused, but doesn't '0-day' mean the exploit was found the day the code in question was released?
Nope. `0-day' means that the vulnerability (with the exploit) is made public before (or the same day) the vendor patch is available. See http://en.wikipedia.org/wiki/0_day, section "Exploits and vulnerabilities".
Re:Sun - Corporate mismanagement at its finest
on
Sun to Cut 5000 Jobs
·
· Score: 1
Jebus, you people (linux zealots) are nuts.
... followed by few paragraphs of Solaris zealotry.
I can throw a system load of 80 at a two-processor box and still get a response (enough of one to fix the problem causing a load of 80). It can run on a 216-processor single-system-image NUMA box efficiently, including some "self-healing" properties.
The same with Linux (well, the biggest box I have used was a 16-way NUMA SGI Altix, but there are 512-way Altixes out there).
Bank of memory throwing correctable ECC errors? Map it out. Processor that has ECC errors in it's cache? Map it out. Hotswap the board containing the processor or memory without a reboot. Users don't notice.
This is a property of hardware, not OS (and of the fact that Solaris runs on a very limited kinds of hardware). Yes, it is definitely better when Solaris can say "the bad RAM is in a bank 3", and you can open the box and see the bank labeled "3", while for example HP DL-585 uses different CPU ordering than Linux (1, 0, 2, 3 instead if 0, 1, 2 3). But this is a property of HW, not OS.
There may be things where Solaris is better than Linux, but there is also a lot of features, where Linux outperforms Solaris. For example, Linux had a NUMA memory allocator long before Solaris, and it can use Read-Copy-Update, while Solaris can't (software patent by IBM granted to GPL'd projects only). Linux can have multiple copies of the kernel text to speed up the NUMA machines. SGI (rest in peace) did a good work on the scalability of the Linux kernel. On the workstation level, the hotplug/udev/hal/d-bus integrated with GNOME comes to mind.
What if the USB driver couldn't DMA a mouse packet over scheduler code
I find it difficult even to imagine how could you acchieve this (not only for USB drivers, but for any generic device out there). Would your firmware loader verify the correctness of the
device firmware (so that it does not allow DMA or verify the DMA address, and of course,
so that it does not contain buffer overruns itself)? How your "magic OS" can fix up the hardware which is plain buggy? It would probably require the virtualization of every single HW component which is available on the target platform, at which point you are nowhere near a
_micro_ kernel:-)
It can be done when you also have the HW platform under your control, but not on a generic PC,
where is no IOMMU (for most devices) to put the sanity checks on.
When are we going to see some real in-depth reviews of released operating systems on Slashdot? As usual, most of the "review" is a bunch of screenshots, mostly of the installation and the startup.
Well, as you can probably guess, it is not only harder to write such an in-depth review, but it also takes more time. So by the time such a review would be released, it would not matter anymore, because FC5 would be close to its end-of-life.
Also, such review would be biased anyway: Hardware support? what hardware? the reviewer cannot have all the hardware FC5 runs on. Performance? I think few percent difference do not matter for most people, and you can sacrify this barely visible amount of power for something more interesting (like virtualization) without anyone (but a review writers:-) noticing. Yes, people would probably be happy they can brag about how their distro runs an infinite loop 5% faster than the other distro:-)
People choose their distributions not by reading some review, but based on whether their friends use it, whether they like the packaging system (RPM vs. Deb vs. plain tgz vs. portage), whether they like the process under which the distro is being developed, whether the distro provides updates for long enough, whether it contains stable (old, boring:-) software, or a bleeding-edge technologies, etc.
I agree with you that the review in TFA is meaningless, and nobody should choose the distribution based on screenshots and the install process. However, I don't think a better or "a real in-depth" review can be written. It is too personal and requires maybe years of daily usage to discover all the pros and cons of the particular distribution. The only thing the reviewer can do is to point out the new technologies behind the distro (such as Avahi or Xen), but that's all. If people are interested in "what's new and interesting" in a distro, they should read the release notes.
The Fedora Download page, which is according to the announcement message supposed to redirect you to one of the mirrors, does not work - it redirects to ftp://download.fedora.redhat.com which is (of course) busy. So let me allow to advertise my mirror - if you are in Europe, I have still about half a gigabit of bandwidth free at
Make sure to future-proof. Even if you don't want a dual-core Athlon 64 today, get a chipset that would support it. This will cut down your chipset choices further.
Thinking about the possible future upgrades is, from my past experience, not worth the money.
I have never ever upgraded just the CPU (even on high-end servers[*]). By the time you decide that the present CPU is too
slow the new CPUs will use better memory interfaces, which means at least the memory upgrade
as well, but the new memory interface usually means the new mainboard infrastructure or new CPU socket. Remember that the memory bandwidth and latency are the main bottlenecks of the current computers - upgrading just the CPU does not solve it.
That said, there is nothing wrong with dual-core support on the chipset per se. Just don't expect you would ever use it as an upgrade path. Instead try to think about the applications this computer will run. Last time I have checked, the prices of (for example) Opteron 254 (2.8 GHz single core) was similar to the price of Opteron 270 (2.0 GHz dual core). If your load can be parallelized (HTTP serving, spam filtering, some databases, etc.), you will benefit from the
additional CPU core, even though both cores are running at the lower frequency. If you have a highly serialized load (workstation?), the higher frequency of the (single) CPU will probably be better.
[*] Well, many years ago we did a CPU upgrade of the SGI Challenge. However, the price of the upgrade was almost the same as the price of the new server.
Linux also falls over at 100,000pps as a router, and FreeBSD happily handles 10 times that.
Any evidence for your claim?
I did not do any synthetic tests, but my Linux router easily handles ~150kpps of real traffic with about 600 iptables rules. I think that just routing would be much faster. I have a ~2 years old dual Opteron 242 with 3 gigabit NICs and one 100mbit NIC.
Ext3 vs. Reiser is not an issue here. FWIW, I use XFS on my mirror volume, and I have also noticed how the git repository increases load on my server. See the CPU usage graph of ftp.linux.cz - look especially at the yearly graph and see how the CPU system time has been increasing for last two months.
The problem is in rsync - when mirroring the remote repository it has to stat(2) every local and remote file. So the directory trees have to be read to RAM. Hashed or tree-based directories (reiserfs or xfs) can even be slower than plain linear ext3 directories, because you have to read the whole directory anyway, so linear read is faster.
Slashdot Mirror
You cannot change the function to use UTF-8 internally without also changing all callers of this function. The same for database - you have to modify (or at least check whether they are doing anything encoding-sensitive such as a case conversions) all places which execute database queries. Sometimes incremental changes are simply not possible.
Sure, they are small changes, but it takes time to find all the places where the change is needed, and they are scattered all over the code base. And the move of the whole application (think web-based information system) to the new UTF-8 environment should be done atomically.
When averything you are doing in your branch are small (one-line) changes like this, you don't have a big problem a month later when you do the merge. Or you can incremenally merge the changesets from the trunk to your own branch (i.e. rebase), and then at the end merge your branch to the trunk.
Simpler solution: stop merging reasonably-sized branches.
There definitely _are_ cases when branching and merging huge branches make sense. One such example is one developer doing huge structural changes all-over the code base, while other developers continue doing their own work (e.g. development of new parts of code). Think changing a previously ASCII-only project to use UTF-8 internally. Or adding i18n support to all strings.
But there's no direct unicode support in the language -- if you're lucky, there are functions you can pipe it through.
3) They're just lists of numbers; they're neither ASCII nor Latin1. There is unicode parsing in the XMERL module.
Which is exactly the problem that GP discussed. There is a huge difference between a true in-language support of Unicode (such as the one in Perl) and just "the Unicode parsing library". In Perl there is a difference between "string of bytes" and "string of characters", and this distinction is made when the string is created (i.e. in the I/O layer when it is read from the file, or in the source code pragma when it is a literal constant). And then all things work as expected (conversion between upper and lower case, word boundaries, string length in bytes or in characters, etc.) - differently on a character string than on a byte string.
This means, that the only place you have to actually "handle" unicode is the point where the data enter your program or leave it. All the other things (libraries etc) just magically work without needing a change. This cannot be easily done without an in-language support (C or maybe Erlang).
Try http://ftp.linux.cz/pub/linux/fedora-releases/9/ (especially if you are in europe). We still have some free bandwidth.
I think there is no way to miss a rollback. Rollback is simply a transaction without commit.
So when you create a FS snapshot with a transaction still in progress, then you will see partial transaction in the log, and maybe rows modified by a transaction which is not explicitly marked as commited, so when you restore from this backup and start the database engine, it will correctly detect it as an unfinished transaction and will not use its data.
The backup with transaction log _cannot_ be made more reliable (if it could, then the database would not be resistent to the host computer crash). It can be faster, easier to restore, etc. But more reliable? No way.
Well, backups over FS (block device, in fact) snapshot sound reasonable to me. After all, database has to be prepared to be in consistent state in case of a filesystem crash.
You may miss few commits just before the snapshot has been created, but in case the database does buffering, you will miss them anyway when/if machine crashes.
The point is that FS snapshot should give you a backup of the database in a consistent state, which is sufficient for most uses.
The OS & Applications simply don't see the difference between two real cores and a hyperthreading core. If I run another thread on a hyperthreading core, I'll slowdown the other thread.
Wrong. Linux scheduler can distinguish between two real cores and a hyperthreading core (i.e. it prefers to run the threads on independent cores). Linux scheduler can also take into consideration core to socket mapping (it prefers to run threads on cores in a single socket in order to allow the other sockets lower their frequency when idle).
Hyperthreading/SMT can hurt performance anyway, because of the bigger L1/L2 cache pressure.
I am eager to replace my current phone with Openmoko. However, I use a SIM Toolkit application for my banking. I wanted to look up whether Openmoko plans some STK support, but I have only found this post in gsmd-devel archives from March. Does anybody know what is the state of SIM Toolkit support in Openmoko?
Hmm, it seems it requires that cookies for www.latimes.com are enabled. With the cookies enabled, the GP link works.
Wrong. Even this link wanted me to register.
I'd rather not.
I often need to read something from one window (an example in the manpage, maybe), and write without looking into another window. This is why auto-raising the focused window is plain wrong (it can obscure the window you want to read from) and this is why using the device from TFA for focus tracking would not be usable.
I can throw a system load of 80 at a two-processor box and still get a response (enough of one to fix the problem causing a load of 80). It can run on a 216-processor single-system-image NUMA box efficiently, including some "self-healing" properties.
The same with Linux (well, the biggest box I have used was a 16-way NUMA SGI Altix, but there are 512-way Altixes out there).
Bank of memory throwing correctable ECC errors? Map it out. Processor that has ECC errors in it's cache? Map it out. Hotswap the board containing the processor or memory without a reboot. Users don't notice.
This is a property of hardware, not OS (and of the fact that Solaris runs on a very limited kinds of hardware). Yes, it is definitely better when Solaris can say "the bad RAM is in a bank 3", and you can open the box and see the bank labeled "3", while for example HP DL-585 uses different CPU ordering than Linux (1, 0, 2, 3 instead if 0, 1, 2 3). But this is a property of HW, not OS.
There may be things where Solaris is better than Linux, but there is also a lot of features, where Linux outperforms Solaris. For example, Linux had a NUMA memory allocator long before Solaris, and it can use Read-Copy-Update, while Solaris can't (software patent by IBM granted to GPL'd projects only). Linux can have multiple copies of the kernel text to speed up the NUMA machines. SGI (rest in peace) did a good work on the scalability of the Linux kernel. On the workstation level, the hotplug/udev/hal/d-bus integrated with GNOME comes to mind.
I find it difficult even to imagine how could you acchieve this (not only for USB drivers, but for any generic device out there). Would your firmware loader verify the correctness of the device firmware (so that it does not allow DMA or verify the DMA address, and of course, so that it does not contain buffer overruns itself)? How your "magic OS" can fix up the hardware which is plain buggy? It would probably require the virtualization of every single HW component which is available on the target platform, at which point you are nowhere near a _micro_ kernel :-)
It can be done when you also have the HW platform under your control, but not on a generic PC, where is no IOMMU (for most devices) to put the sanity checks on.
Well, as you can probably guess, it is not only harder to write such an in-depth review, but it also takes more time. So by the time such a review would be released, it would not matter anymore, because FC5 would be close to its end-of-life.
Also, such review would be biased anyway: Hardware support? what hardware? the reviewer cannot have all the hardware FC5 runs on. Performance? I think few percent difference do not matter for most people, and you can sacrify this barely visible amount of power for something more interesting (like virtualization) without anyone (but a review writers:-) noticing. Yes, people would probably be happy they can brag about how their distro runs an infinite loop 5% faster than the other distro :-)
People choose their distributions not by reading some review, but based on whether their friends use it, whether they like the packaging system (RPM vs. Deb vs. plain tgz vs. portage), whether they like the process under which the distro is being developed, whether the distro provides updates for long enough, whether it contains stable (old, boring:-) software, or a bleeding-edge technologies, etc.
I agree with you that the review in TFA is meaningless, and nobody should choose the distribution based on screenshots and the install process. However, I don't think a better or "a real in-depth" review can be written. It is too personal and requires maybe years of daily usage to discover all the pros and cons of the particular distribution. The only thing the reviewer can do is to point out the new technologies behind the distro (such as Avahi or Xen), but that's all. If people are interested in "what's new and interesting" in a distro, they should read the release notes.
It means gigabit/s, of course, this mirror has no data transfer limit. Anyway, sorry for the typos and two signatures in the previous post.
The Fedora Download page, which is according to the announcement message supposed to redirect you to one of the mirrors, does not work - it redirects to ftp://download.fedora.redhat.com which is (of course) busy. So let me allow to advertise my mirror - if you are in Europe, I have still about half a gigabit of bandwidth free at
ftp://ftp.linux.cz/pub/linux/fedora-core/5/
-Yenya
Make sure to future-proof. Even if you don't want a dual-core Athlon 64 today, get a chipset that would support it. This will cut down your chipset choices further.
Thinking about the possible future upgrades is, from my past experience, not worth the money. I have never ever upgraded just the CPU (even on high-end servers[*]). By the time you decide that the present CPU is too slow the new CPUs will use better memory interfaces, which means at least the memory upgrade as well, but the new memory interface usually means the new mainboard infrastructure or new CPU socket. Remember that the memory bandwidth and latency are the main bottlenecks of the current computers - upgrading just the CPU does not solve it.
That said, there is nothing wrong with dual-core support on the chipset per se. Just don't expect you would ever use it as an upgrade path. Instead try to think about the applications this computer will run. Last time I have checked, the prices of (for example) Opteron 254 (2.8 GHz single core) was similar to the price of Opteron 270 (2.0 GHz dual core). If your load can be parallelized (HTTP serving, spam filtering, some databases, etc.), you will benefit from the additional CPU core, even though both cores are running at the lower frequency. If you have a highly serialized load (workstation?), the higher frequency of the (single) CPU will probably be better.
[*] Well, many years ago we did a CPU upgrade of the SGI Challenge. However, the price of the upgrade was almost the same as the price of the new server.
The TFA does not discuss what exactly is the difference between these new boxes and Sun's older Opteron offerings, V20z and V40z.
Any evidence for your claim?
I did not do any synthetic tests, but my Linux router easily handles ~150kpps of real traffic with about 600 iptables rules. I think that just routing would be much faster. I have a ~2 years old dual Opteron 242 with 3 gigabit NICs and one 100mbit NIC.
You forgot SGI (I've counted 10 SGIs in TOP 100, including #3).
Ext3 vs. Reiser is not an issue here. FWIW, I use XFS on my mirror volume, and I have also noticed how the git repository increases load on my server. See the CPU usage graph of ftp.linux.cz - look especially at the yearly graph and see how the CPU system time has been increasing for last two months.
The problem is in rsync - when mirroring the remote repository it has to stat(2) every local and remote file. So the directory trees have to be read to RAM. Hashed or tree-based directories (reiserfs or xfs) can even be slower than plain linear ext3 directories, because you have to read the whole directory anyway, so linear read is faster.
My mirror has still lots of bandwidth left. Feel free to use it, especially when you are in Europe.
Actually the author's surname is Klíma, not Klýma (Klima in ASCII).