Basically they are replacing the spark plugs when they could be switching to an electric engine. A huge amount of overhead comes from system calls, context switches, and data copying -- three things that effectively cannot be eliminated if the system runs unsafe code. You can *sometimes* eliminate data copying in specific cases using shared memory or complex operations (sendfile), but not normally.
I recently found this paper which claims:
* 20%-80% performance by the compiler placing parameters in a shared memory so the kernel does not have to copy data
* 60-80% from doing multiple calls as one (ie, readdir-stat, open-read-close)
* 40-90% from putting some parts of the app logic in the kernel even with safety checks inserted into the code
This suggests that the average overhead of say 1.5x from Java code running in the kernel over C code would be dwarfed by the inefficiencies of actually running that C code safely. This is the kind of thing they should be working on.
It's probably more likely that our eyes just are not able to accurately position on a page of text. The brain tells both eyes to 'look at' the same exact place, but due to variations in muscle response and delays getting the command sent to the eye they end up at slightly different places.
You could probably reduce this error though by putting features on the page of text that let the eye track better than vast areas of white. For instance if the same shape and size text was engraved in natural wood the eye would probably be a lot more accurate in positioning to a specific letter.
I doubt this is any more a strategy for reading than it is just a fact of life.
More likely still is that the server responsible for simulating that section of the universe crashed and hasn't been restarted yet (or will never restart). The civilization there probably started using too many quantum calculations causing the simulation to take too long doing useless things like reversing encryption keys instead of sending us more photons.
In any case, I would not worry about this since we'll probably just be rolled back to a known-good state once the problem has been fixed.
Yeah right... most machines sound takes far less than 0.1% of the CPU time to 'push the bits'. Even if you write it in C++ or asm it "might work on some people's computers and not on other". Ooh scary.
These methods get inlined directly by the JIT since it knows the final types so these buffers are generally equivalent to arrays in overhead. They do check bounds though, but if you want to crash your sound app go ahead and write it in C++.
The OP was wrong about the Java API because he was not aware of java.nio.* existing. You are wrong about the performance impact. You are right about not using nondeterministic features for a realtime application (runtime of malloc/free aka new/delete is nondeterministic fyi). Of course you could pre-allocate your buffers and other objects in Java just like you can in C++.
With pointer semantics I can simply treat the byte array like a short array and be done with it. byte data[] =...; ShortBuffer sb = ByteBuffer.wrap(data).asShortBuffer(); short val = sb.get(index);
Actually performance is not what killed the microkernel. I've actually read some of the original detailed performance studies (ie 200+ page reports) on Mach and it simply was not the case that is was much slower than monolithic kernels. Not enough to make a substantial difference.
The actual problem was the concept of the microkernel itself. When you protect servers from each other you add another layer of complexity to the interaction, and this is good in theory but in practice it gets in the kernel hackers' way. There are many examples in Linux and other kernel of the moral equivalent of "public static int aglobal" or "otherserver->somevar->aprivate" that get put in as a shortcut just to get something working. Or in other cases fields (see inode) that get overloaded with values from what would be many different servers in a microkernel. It's the development model of microkernels that killed them.
In the old times like say with Amiga, *all* programs essentially ran in the kernel. These systems were far faster than any micro or monolithic kernel at timings and interrupts and context switches, with much better 'feel' and 'smoothness', but they died because they crashed (nowdays they would die because of insecurity). So the monolithic kernel is a local maxima between crashing/insecurity and too much developer overhead. Unfortunately, it's also a really bad one that we are stuck in (safe language for everything, kernel + 'userspace' is very much better).
The point is to create a scheduler that performs well on desktop workloads. That's the point. One desktop workload is playing video games, and as you point out people do *not* play games with several 100% CPU loads going on the background. But there are hundreds of things that happen automatically, such as your clock updating once per second, your web page with news pages that reload every couple minutes, checks for new email, some occasional updates for xfire / pidgin / etc. Things that will typically do a lot of context switches for short durations. My point is that the setup Ingo used was about the worse gaming benchmark one could possible come up with, and conveniently it favored CFS as much as really possible. To me this sounds like somebody purposely trying to defend his scheduler.
And don't get me started on updatedb. Why is it necessary? Because the kernel devs won't put something in that lets usermode see all file changes. Inotify is barely even usable with all sorts of timing issues catching new folders, mounts, etc. Dropped update messages because the watching program didn't read enough events fast enough, very small limits on the number of watch devices and number of inode that can be watched (for example only ~1/2 of the folders on my system can be watched even using all the available watch devices), difficulty correlating inodes into the right place in the fs tree. If you miss anything the watching application has to rebuild its whole view of the watched part of the fs in order to be correct, updatedb style. This kind of problem is begging for a VM like neko as the moral equivalent of a souped up berkeley packet filter but I'll put my money on you NEVER seeing a vm in linus's tree, even one that takes only 200k. At least directly copy the change records directly into the program's space so there's nothing dropped.
Free speech is not an absolute right to say anything you want, just like freedom of religion is not a free pass to breed with your cousin, and freedom to petition doesn't mean you can assembly in the middle of the interstate and shut it down.
The problem we have these days is that people on Fox, CNN, and some other networks can say pretty much whatever they want, live, broadcast to millions of people and there is next to no consequences when it is wrong, misleading, or slanderous. Then put a line under John Conyers' picture that said something like "caught with 90k in his freezer" when that was Jeffords (but hey they are both black). Not even a retraction or apology later. They need to be fined for that kind of 'mistake', or at least a very easy and cheap way to get default judgements in court. Media companies need to be liable for what their guests say on the air.
Yeah, media companies would have to do fact-checking and delayed broadcast, but those are good things. It's not an infringement of their free speech (as if a company has rights under the constitution to begin with), it's just their responsibility in a civil society.
Note that this kind of vulnerability can happen in anything using unsafe code. It is not an indictment against Java's security model, it's just a bug in the native code libraries used to make the implementation faster. Also.NET uses more native code than Java so one would expect similar kinds of bugs to affect it.
This kind of problem will not exist once all of our libraries and operating systems have been written in safe languages such as Java.
The problem is that everything you do that you don't want at least one person to know about is a potential way to blackmail you. For example, do you limit your donations to the Democrats to less then $250 because you know your Republican boss can check online to see which employees to fire or not promote or not give a raise to? That's an implicit blackmail.
Then there is explicit blackmail, like the person with access to the database that sees who is driving in crackville and threatens to report them, unless. Or the person who makes obvious 'detours' to his secretary's apartment every so often.
Privacy is like bees. A particular bee or any given sting might seem like a small problem, but once you get a whole cloud of them around you then your only chance is to freeze and hope your clothes don't look pretty in ultraviolet. It's not even so much a slippery slope as it is a death by a thousand cuts.
If GPLv4 was an evil MS license then MS can use all previous GPLv2 and GPLv3 or later code in a totally locked up proprietary product. GPL: "The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns."
If the spirit of the license is not similar then the later version cannot be used. Even if Microsoft were to somehow buy out FSF they can't lock up GPL'ed code, even "or later version" code. Judges interpret the law and are generally not completely retarded, so the hypothetical evil GPLv4 would be found to be not a later version of the earlier GPL licenses.
Finally (because I think we look very weird, arguing in a days-old buried Slashdot thread:-), For sure. But there are just a few more points I would like to make:
Re: DRM, yes you can change your position if and when they flip the giant switch preventing you from controlling your own computer, but what you cannot do it relicence past version of linux so that it will be illegal to use on such systems. So, if that were to come about then any influence developers have would start at that point. On the other hand, by doing something now you can preemptively build up over time more and more of a negative consequence from flipping that switch. For example, if a law is going to be passed that would stop Dell from installing Ubuntu on their systems then Dell is going to be pissed about that. That's a real market force that will be caused by GPLv3.
And if, as I expect, there's no problem at all, then Linux will not have restricted its user base unnecesarily. Win-win. The lesson from GPL vs BSD is that it is the restrictions in GPL that cause greater collaboration and growth of free software. The restriction to not take the code and run away with it. Frankly Tivo already picked linux despite the license and they probably would have done so anyway with a GPLv3-like no-DRM clause because they could build a cheaper box with it than with BSD, and cheaper than Replay TV licensees could. If they didn't, maybe we would all be using Replay instead (which imo is a much better dvr). If they did, we could still skip commercials despite industry pressure on Tivo not to. So I don't see how you can just say that not having some restriction is necessarily a 'win'. I think you are just assuming it would be a win because that aligns with your existing views. This is the 'just right' attitude that Linus and some kernel devs have that GPL2 just happens to be 'just right' -- as far as I have seen there's not really any justification for that.
As of the "mainstream of the free software camp" (nice term, that one), well, that's funny, I think it's you, along with most FSF advocates, who are a bit disconnected from certain realities of the software world, particularly regarding competition against big software makers for the favor of the unwashed masses. But let's not argue about this. I am basing this on the discussions over GPL I have read, and talking to people at FSF and Red Hat, and other sources. This is why I posted my original message, because all the indication I have seen is that over time Linux kernel is going to be the odd-man-out, like BSD is today. It may still be 'the kernel' for a long time, but it's not going to be cool and the next generation of coders is going to ask why it's not "real GPL".
That sounds like what they are doing, improving performance by making more things native.
For example, they could put a Java bytecode interpreter "cpu" into the system. Java CPUs didn't take off because a mainstream processor would always have better process and funding, and you had to totally switch to Java. But if everybody had a Java "cpu" that only cost $0.25 extra to put in the chip and got faster as the main CPU got faster, then it might actually be useful (incidentally.NET bytecode is too complicated to run directly in a cpu).
Alternatively, they could put in generic garbage collection as a separate processor that runs all the time. This could accelerate Python, Java,.net, perl, ruby, smalltalk, and any number of other 'slow' languages that people are using anyway. The can add in a cell-like cpu who's only purpose is lzw-style compression or hashes, or these could be just *really* slow uninterruptible instructions only available on some cores... leaving others to handle interrupts and whatnot.
I don't think multi-threaded code is necessarily the only way to take advantage of multiple cores.
Maybe it's that GPLv2 happens to be an adequate common ground what seems to have made people like you believe, mistakenly, that you shared the Linux point of view. Just like it made people like me believe, also mistakenly, that I shared the FSF's point of view. For my part, I now realize that this is not the case. I also believe my point of view is the better one, of course.
That is a good description actually. In the past, people generally thought Linux (kernel) was free software when it now looks like Linux was just 'using' the free software camp to get ahead and did not really have any philosophical commitment to free software. It's clear that a large number of linux kernel developers are committed to open-source software not free software.
You mean that "early drafts" thing? I say that not because of the draft's rough quality but because they made me aware of the direction the FSF intended to take, the things they consider important. As I said, I mistakenly believed that I shared their convictions. That was a rude awakening of sorts. And yes, it was entirely my mistake. Like, for instance, somehow I misunderstood or disregarded Stallman's writings. My bad, won't happen again.
You basically said that it was the 'early drafts' that really woke you up to where free software was going and made you glad there was no upgrade clause in linux, but there has been a lot dropped out of GPLv3 since those drafts. I implied that to mean it was the content of the early drafts that your were upset about and not also what is in the latest version.
GPLv3 goes too far in its attempt to "protect the rights" of everyone. If someone wants to take my code and build a machine that doesn't boot modified software images, say a phone or some specialized portable device, as long as they release the source code I'm cool with that, but GPLv3 forbids it. If they want to write a client for SecondLife or some such, where the software bars the user from copying graphics or models or whatever, then they can't use my code either, because then they couldn't pursue patches disabling that restriction as "circunvention devices" under WIPO. Or so I think. Tell me if I'm wrong, because section 3 of the current draft is barely comprehensible
I think you forgot the clause "as long as I can still run the code on my own computers". It's not clear to me that market forces are sufficient to protect running any code we want on our own computers. I assume you are familiar with things like EFI which are part of a concerted effort to have DRM at every stage of the computer (most of which is already in place). That people cannot distribute GPL'ed software on such a machine without giving the ability to run modified software can only help to prevent this. In my opinion, section 3 pretty clearly states that you cannot use DRM that prevents the software from being modified. You could include DRM in hypothetical SecondLife client, but anybody could just compile it out again or modify the software to bypass it.
Anyway, that's another gripe I have: this new license is written in Legalese, rather than English. I think for J. Average Hacker is obscure and in parts plainly incomprehensible, like section 3 or section 6 of the current draft.... The GPLv2 is clear, simple, and has never been challenged in court, afaik. So what's the problem again?
I find the GPLv2 vague and ambiguous in many ways. While it is longer and more detailed, I find GPLv3 easier to understand when I have a particular question (ie is this allowed by license?). From what I have read of the comments I also understand that it has corrected a number of deficiencies (such as expiration, warning periods, etc). So I have to disagree with you on this.
But Linux is not GPLv3, so we'll never know. However, Sun can choose to release under GPLv3 to be the FSF's "good guy", but alienating Linux developers in the process; or it can release under GPLv2 ("or later"
Right. But that's no different than the CDDL. Right now, to use ZFS you have to be able to glue a chunk of CDDL code into your project. Linux can't use it because of the GPL (any version). Shouldn't we, by your reasoning, say that that's Linus' fault for choosing the GPL instead of something else?
CDDL did not exist at the time, so it was not even a choice. Supposing it did, it is an open source license rather than a free software license, so comparing choice of CDDL vs GPL is a philosophical choice rather than an 'implementation' choice. So to answer your question, no we should not.
Linus is now preemptively blaming Sun for releasing ZFS under GPLv3, if they do, which would mean that Linux can't use it. What I am saying is that, like the bitkeeper fiasco, choosing to use *only* GPLv2 now looks like a big short-sighted mistake. And that this was Linus & Co's decision not Sun's.
Well, that's your perception. The short-sighted mistake, I mean. To me, it was a sensible choice. If you care about how people use your code, then you don't leave a backdoor for third parties to relicense your code as they see fit. Not even the FSF.
Well would you reasonably expect GPLv2 to be the last word on free software licenses? Would you expect people to never start using later version of GPL? You can in essence say 'well we want to have ultimate control over our code', which is what I said in my previous post, but not having an upgrade path is just poor planning. For example, code submitters could be able to opt-out of a license change Linus wanted to make -- that gives you the same rights to not have your code license changed but would allow Linux to easily get to GPLv3 but still only if it were generally acceptable to the developers at large.
In fact, and this will sound trollish, and I do apologise for that, but after reading the GPLv3, particularly the early drafts, I have to qualify: especially not the FSF.
I find this ironic because if you judge Linux by its rough drafts (early versions) then a lot of the code is simply a joke. It certainly did not come out of the ether fully formed. Many would have called the process used to develop it all manner of derogatory words, but what matters is what the results are. And GPLv3 looks to be much better than GPLv2 in a lot of ways; the process works.
Is anybody seriously saying Sun should release their code under the soon to be out-of-date GPLv2 simply because Linus 'likes' GPLv2 better? That's pretty absurd, and I assume you would agree.
I'm really sorry for being difficult, but no, I would not agree. C'mon, I keep reading GPLv3 advocates saying as much: GPLv2 is not going anywhere, you are as free to use it as you are to choose GPLv3. Now, regardless of how things got the way they are, or whose "fault" was it, Linux is GPLv2, and it doesn't seem likely that that will change anytime soon. Sun can choose GPLv2 if they want. In fact, I think there's a good chance they'll do precisely that, just so they can use the drivers.
I have read the comments and followed the evolution of GPLv3. There are a lot of good changes that are sometimes not obvious without explanation, such as adding an expiration so the license is more solid in some countries. Or removing ties to U.S. law, or using words that do not already have an established legal meaning. Or clarifying what a covered work is. And so on.
Sure, Sun can license their code using GPLv1 or GPLv2, but why should they use a license with known problems? Like you say it may be been done on purpose so that Linux cannot use the code, but by being limited to GPLv2 linux is giving Sun this opportunity to be the good guy -- looking at it objectively and independently Sun using GPLv3 is not just supporting free software but actively advancing it. If linux had some way to use GPLv3 then if your cynical theory is correct
GPLv3 does not 'give away' patents, it lets people use them for the covered work and modifications of it and only as long as the license is in effect (not terminated or breached). For example, if Microsoft clean-room implements ZFS then Sun can sue them over those 50 patents even though Microsoft may at the same time be legally using the GPL3'd ZFS code in other products. If somebody takes ZFS code and uses it in their storage product without giving back the changes or otherwise breaches GPL, then Sun could sue them not only for copyright infringement but also for those patents. If somebody makes a similar filesystem not based on ZFS code then Sun can sue them over the patents.
GPLv3 actually helps Sun to have their codebase as the defacto standard, because any implementation would have to be based on Sun's code. And the definition of based on means that it would require the copyright permission, which means that any such work would also be under GPLv3 (and possible also other compatible licenses). In other words, if it doesn't have any of Sun's code in it then it isn't 'based on' Sun's ZFS and so doesn't have patent protection.
First, the kernel devs (not only Linus) chose GPLv2 because they liked it. They don't seem to like GPLv3, so removing the "later version" language was evidently a prescient and wise move. Ultimately Linus (and whoever else) made the choice to use GPLv2 and only GPLv2. Linus is now preemptively blaming Sun for releasing ZFS under GPLv3, if they do, which would mean that Linux can't use it. What I am saying is that, like the bitkeeper fiasco, choosing to use *only* GPLv2 now looks like a big short-sighted mistake. And that this was Linus & Co's decision not Sun's. Is anybody seriously saying Sun should release their code under the soon to be out-of-date GPLv2 simply because Linus 'likes' GPLv2 better? That's pretty absurd, and I assume you would agree.
Now, if Sun actually steps ahead and does it, I will gladly take back all this, apologise, and run to the kitchen to get some Tabasco for my nice plate of crow. And I will enjoy chewing on it, because it would be great to have ZFS. But, like Linus, I won't hold my breath waiting for that to happen. If Sun actually does release ZFS under GPLv3 Linux developers and users won't be enjoying that crow because Linux will still not have it in the kernel. It'll have a FUSE only slow version or have a legitimate patent cloud hanging over it. The existing FUSE ZFS would also have a patent cloud over it until they base it on Sun's implementation and thus release it under GPLv3 license.
Finally, you poo-poo software patents. I don't actually have a problem with software patents, what I have a problem with is bogus ones (one click, FAT32, etc) and patent trolls (patents owned by those who did not create them). It seems to me that there may be some actual non-obvious and new ideas in ZFS and if so then Sun should be rewarded in some way for coming up with them.
Linus:
And yes, maybe ZFS is worthwhile enough that I'm willing to go to the effort of trying to relicense the kernel. This looks like Linus saying that ZFS will be the main differentiator for unix-like systems. Apparently ZFS is so much better that Linux must adapt in whatever way practical in order to get it. I think this is really the key to understanding where Linus is coming from. ZFS is looking to be the defacto standard for filesystems for the next decade and even if Linus tries to change the kernel to GPLv3 it will still be years behind Solaris on this. ZFS is already in Solaris, Mac OS X (rsn), and FreeBSD.
What we see here is Linux already starting to be held back by requiring what will be an older out-of-date license and Linus already starting to blame others for it, when with his stewardship it is his choice that caused it. Linux can't use a GPLv3 ZFS because Linus is against using the GPLv3 license. Linus removed the "or later version" clause because he wanted more control over the kernel. The only question is how stubborn and obstinate Linus will be before he decides to support GPLv3, and how much will that hurt Linux.
NTFS has data checksums to detect and repair corruption caused by any component? Yes & No - All FS models implement checksuming features. Although, no it is not to the same checksum level as you are going for, although it is far less impressive or important than you seem to think it is. The answer is NO, NTFS does not do data checksums or any checksums at all. The only checksum it has is for the bootsector, and it doesn't check it and it is often wrong. What you seems to be talking about is meta-data only sanity checks. These are totally different from checksums. Ironically, NTFS does not have much problem with data corruption since drives are often unoptimally defragmented (a moved block gives the hardware a chance to detect weak sectors). ZFS does sanity checks and also checksums of all data and all metadata.
NTFS does data-level journaling not to mention without the overhead of multiple writes of the data? Yes - Go look up the original NT journal features from 1991, and the expanded features used in Vista. NTFS does meta-data only journaling. It may be technically capable of doing data-level journaling (using multiple writes of the data) but it does not do this. ZFS always does the equivalent of data journaling and with no extra writes of the data.
NTFS can use compression without getting horrible fragmented or other negative side effects? Yes - Compression offers no more fragmentation than normal NTFS writes. This is insane. NTFS compresses files in 64k segments, then writes these segments to the file packed one after another. When a segment grows larger due to data being modified, the file is fragmented. The location of compressed blocks within a file is stored in MFT linearly, and compressing a large file causes more MFT blocks to be allocated (often causing additional fragmentation). Changing one 4k block causes 64k to be decompressed then recompressed again. This is very, very inefficient compared to ZFS. For example, try using NTFS to compress a vmware image (do not try this on your actual system however...) and then use that system for a while. ZFS has no problems doing this.
NTFS snapshots do not affect performance of the normal system? Yes - Snapshots, oh yes, have you not heard of 'previous versions' or System restore, they are built on the NTFS's various snapshot abilities. NTFS snapshots slow down writes to files. ZFS snapshots do not.
For a 1992 FS(NTFS), that STILL is ahead of MOST other FS avaiable, with the exception of a few features you can pick and chooses, you are making are really stupid argument here. You said "NTFS on the other hand has been doing this stuff for quite some time" in response to features NTFS does not have. This is what I object to. Most NTFS features were done before in JFS, VxFS. NTFS does have more bullet points then most filesystems, but most filesystems implement each bullet point better than NTFS.
So once again, for the Mac world, ZFS is an awesome way to go if they can get the performance in line with their needs. However it is STILL just catching up with NTFS which is very feature rich and very solid and won't be hitting any walls for storage sizes in the next 10-15 years No, you are still not getting it. ZFS has many features that NTFS does not have and never will because of its fundamental design. The reverse is also true to some extent, for example your point about ZFS and small writes/rewrites (although ZFS is already faster than UFS on this).
Am I not allowed to believe both ZFS and NTFS are good technologies? If you believe that ZFS is merely 'catching up' to NTFS then you would be very wrong. You seem to believe that from the tone of your posts.
NTFS has data checksums to detect and repair corruption caused by any component? You can add and remove disk space from an NTFS volume dynamically? NTFS does data-level journaling not to mention without the overhead of multiple writes of the data? NTFS can use compression without getting horrible fragmented or other negative side effects? NTFS snapshots do not affect performance of the normal system? NTFS has variable block sizes? NTFS is open source and took less than a decade to get support on multiple systems?
As far as I know that's a big no on all those. I mean NTFS is very complex and has a lot of bullet points, but to claim that ZFS is just 'ntfs with larger address space' is really missing the boat.
"However, after I take a snapshot of a volume, the write performance to the original volume is degraded by about 5 times. Why such a big degrade?"
"The advice seems to be to take the snapshot, mount it, copy the data off, and remove it as quickly as possible."
If you are using LVM snapshots for making a Time Machine you might as well do your video editing in vmware and use their snapshots. Either way it's going to be slow as hell. ZFS snapshot and LVM snapshots are worlds apart.
ZFS is several orders of magnitude better at streaming large files like are used in video editing, which is already a huge draw for Macs. Since it is copy-on-write, writes are done without seeking so are very fast and can be spread out across multiple drives in parallel. IIRC within a zfs pool (collection of drives) you can make different 'filesystems' mirrored or striped, so you can have a/video that is striped and ultra-fast whereas/home is mirrored and fault-tolerant.
You can take your 100gb video and instantly say 'snapshot this' then make any number of changes to it and if you don't like it just revert back again. Contrast to every other filesystem (besides spirolog) where you have to make a 100gb copy as a backup -- which takes forever, so nobody does it unless they have to.
You can drop in a new drive and say 'use this drive' and your existing filesystem instantly has more space available and it is more fault tolerant or faster or both. If you want to remove a drive you say 'dont use this drive' and you can still use the OS normally while it moves data off to other drives.
Something like ZFS, that "touches so many other applications and parts of the OS" has to be the default. Otherwise you have to support two completely different ways of using the system. And that bloat and complication costs a lot more than just getting it right through extensive testing. If you are really worried about it, don't upgrade the OS for a while.
But that's the problem with subversion... the things that one might normally do all the sudden are 'fiddling with stuff you are not supposed to fiddle with' and a big 'no-no'.
1) You want to make a copy of trunk to send to somebody:
tar cvf project.tar .
With svn you have to go through a bunch of magic to do this or you end up giving them an original copy when you may have local changes (you tweaked some config option or whatever), your username, time svn repo address and structrure, etc. If you do svn export it makes a copy of what is in HEAD not in your folder, so there is no way to do this without going back and weeding out this junk
3) You make a copy of a file and then decide to rename it (or other cases).
# svn cp/other/file.c file.c
# svn mv file.c newname.c
svn: Use --force to override
svn: Move will not be attempted unless forced
# svn --force mv file.c newname.c
svn: Cannot copy: it is not in repo yet; try committing first
Svn says you *must* do a bogus commit because you wanted to rename a file, or alternatively you can revert the new file and lose it? wtf? dumb.
That's right you have to break out your bash/perl script skills to do this. Lame.
There's a *lot* to dislike about svn. It's basically just 'icky' all throughout. The checkouts are huge and ugly, many operations are slow (compared to monotone), its really annoying to have a private repo that you sync occasionally so you end up with zillions of tiny commits or losing work because you didn't commit enough. And the repo itself is very large -- converted a 2g repo from svn to monotone preserving revisions and even with straight add/del instead of renames/moves the monotone database was a small fraction of the size, about 1/6th. Incidentally, the monotone version was much faster in pretty much every way.
Monotone is technically much better than subversion, except for one problem that you can't checkout only a subset of a repo. Maybe they have fixed that by now and if so it would be crazy to use svn instead of it IMO. I'm sure there are also many others out there better than svn.
Slashdot Mirror
Basically they are replacing the spark plugs when they could be switching to an electric engine. A huge amount of overhead comes from system calls, context switches, and data copying -- three things that effectively cannot be eliminated if the system runs unsafe code. You can *sometimes* eliminate data copying in specific cases using shared memory or complex operations (sendfile), but not normally.
I recently found this paper which claims:
* 20%-80% performance by the compiler placing parameters in a shared memory so the kernel does not have to copy data
* 60-80% from doing multiple calls as one (ie, readdir-stat, open-read-close)
* 40-90% from putting some parts of the app logic in the kernel even with safety checks inserted into the code
This suggests that the average overhead of say 1.5x from Java code running in the kernel over C code would be dwarfed by the inefficiencies of actually running that C code safely. This is the kind of thing they should be working on.
It's probably more likely that our eyes just are not able to accurately position on a page of text. The brain tells both eyes to 'look at' the same exact place, but due to variations in muscle response and delays getting the command sent to the eye they end up at slightly different places.
You could probably reduce this error though by putting features on the page of text that let the eye track better than vast areas of white. For instance if the same shape and size text was engraved in natural wood the eye would probably be a lot more accurate in positioning to a specific letter.
I doubt this is any more a strategy for reading than it is just a fact of life.
"Made in ..." trumps "Copied design from ..." any day.
More likely still is that the server responsible for simulating that section of the universe crashed and hasn't been restarted yet (or will never restart). The civilization there probably started using too many quantum calculations causing the simulation to take too long doing useless things like reversing encryption keys instead of sending us more photons.
In any case, I would not worry about this since we'll probably just be rolled back to a known-good state once the problem has been fixed.
Yeah right... most machines sound takes far less than 0.1% of the CPU time to 'push the bits'. Even if you write it in C++ or asm it "might work on some people's computers and not on other". Ooh scary.
These methods get inlined directly by the JIT since it knows the final types so these buffers are generally equivalent to arrays in overhead. They do check bounds though, but if you want to crash your sound app go ahead and write it in C++.
The OP was wrong about the Java API because he was not aware of java.nio.* existing. You are wrong about the performance impact. You are right about not using nondeterministic features for a realtime application (runtime of malloc/free aka new/delete is nondeterministic fyi). Of course you could pre-allocate your buffers and other objects in Java just like you can in C++.
ShortBuffer sb = ByteBuffer.wrap(data).asShortBuffer();
short val = sb.get(index);
So... you were saying?
Actually performance is not what killed the microkernel. I've actually read some of the original detailed performance studies (ie 200+ page reports) on Mach and it simply was not the case that is was much slower than monolithic kernels. Not enough to make a substantial difference.
The actual problem was the concept of the microkernel itself. When you protect servers from each other you add another layer of complexity to the interaction, and this is good in theory but in practice it gets in the kernel hackers' way. There are many examples in Linux and other kernel of the moral equivalent of "public static int aglobal" or "otherserver->somevar->aprivate" that get put in as a shortcut just to get something working. Or in other cases fields (see inode) that get overloaded with values from what would be many different servers in a microkernel. It's the development model of microkernels that killed them.
In the old times like say with Amiga, *all* programs essentially ran in the kernel. These systems were far faster than any micro or monolithic kernel at timings and interrupts and context switches, with much better 'feel' and 'smoothness', but they died because they crashed (nowdays they would die because of insecurity). So the monolithic kernel is a local maxima between crashing/insecurity and too much developer overhead. Unfortunately, it's also a really bad one that we are stuck in (safe language for everything, kernel + 'userspace' is very much better).
The point is to create a scheduler that performs well on desktop workloads. That's the point. One desktop workload is playing video games, and as you point out people do *not* play games with several 100% CPU loads going on the background. But there are hundreds of things that happen automatically, such as your clock updating once per second, your web page with news pages that reload every couple minutes, checks for new email, some occasional updates for xfire / pidgin / etc. Things that will typically do a lot of context switches for short durations. My point is that the setup Ingo used was about the worse gaming benchmark one could possible come up with, and conveniently it favored CFS as much as really possible. To me this sounds like somebody purposely trying to defend his scheduler.
And don't get me started on updatedb. Why is it necessary? Because the kernel devs won't put something in that lets usermode see all file changes. Inotify is barely even usable with all sorts of timing issues catching new folders, mounts, etc. Dropped update messages because the watching program didn't read enough events fast enough, very small limits on the number of watch devices and number of inode that can be watched (for example only ~1/2 of the folders on my system can be watched even using all the available watch devices), difficulty correlating inodes into the right place in the fs tree. If you miss anything the watching application has to rebuild its whole view of the watched part of the fs in order to be correct, updatedb style. This kind of problem is begging for a VM like neko as the moral equivalent of a souped up berkeley packet filter but I'll put my money on you NEVER seeing a vm in linus's tree, even one that takes only 200k. At least directly copy the change records directly into the program's space so there's nothing dropped.
Free speech is not an absolute right to say anything you want, just like freedom of religion is not a free pass to breed with your cousin, and freedom to petition doesn't mean you can assembly in the middle of the interstate and shut it down.
The problem we have these days is that people on Fox, CNN, and some other networks can say pretty much whatever they want, live, broadcast to millions of people and there is next to no consequences when it is wrong, misleading, or slanderous. Then put a line under John Conyers' picture that said something like "caught with 90k in his freezer" when that was Jeffords (but hey they are both black). Not even a retraction or apology later. They need to be fined for that kind of 'mistake', or at least a very easy and cheap way to get default judgements in court. Media companies need to be liable for what their guests say on the air.
Yeah, media companies would have to do fact-checking and delayed broadcast, but those are good things. It's not an infringement of their free speech (as if a company has rights under the constitution to begin with), it's just their responsibility in a civil society.
I think looking for the word "droids" you are.
It's probably Security Vulnerabilities in the Java Runtime Environment Image Parsing Code May Allow a Untrusted Applet to Elevate Privileges, which sounds like a flaw in native code that loads images.
.NET uses more native code than Java so one would expect similar kinds of bugs to affect it.
Note that this kind of vulnerability can happen in anything using unsafe code. It is not an indictment against Java's security model, it's just a bug in the native code libraries used to make the implementation faster. Also
This kind of problem will not exist once all of our libraries and operating systems have been written in safe languages such as Java.
The problem is that everything you do that you don't want at least one person to know about is a potential way to blackmail you. For example, do you limit your donations to the Democrats to less then $250 because you know your Republican boss can check online to see which employees to fire or not promote or not give a raise to? That's an implicit blackmail.
Then there is explicit blackmail, like the person with access to the database that sees who is driving in crackville and threatens to report them, unless. Or the person who makes obvious 'detours' to his secretary's apartment every so often.
Privacy is like bees. A particular bee or any given sting might seem like a small problem, but once you get a whole cloud of them around you then your only chance is to freeze and hope your clothes don't look pretty in ultraviolet. It's not even so much a slippery slope as it is a death by a thousand cuts.
Ah, the GNU/Generation. In Linus/Linux speak:
/proc/sys/kernel/voodoo
# cat
1: 10 5:5 8 7 13 20 0x00000022
--
GNU: A recursive acronym "GNU's Newbie Unix"
"The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns."
If the spirit of the license is not similar then the later version cannot be used. Even if Microsoft were to somehow buy out FSF they can't lock up GPL'ed code, even "or later version" code. Judges interpret the law and are generally not completely retarded, so the hypothetical evil GPLv4 would be found to be not a later version of the earlier GPL licenses.
Re: DRM, yes you can change your position if and when they flip the giant switch preventing you from controlling your own computer, but what you cannot do it relicence past version of linux so that it will be illegal to use on such systems. So, if that were to come about then any influence developers have would start at that point. On the other hand, by doing something now you can preemptively build up over time more and more of a negative consequence from flipping that switch. For example, if a law is going to be passed that would stop Dell from installing Ubuntu on their systems then Dell is going to be pissed about that. That's a real market force that will be caused by GPLv3. And if, as I expect, there's no problem at all, then Linux will not have restricted its user base unnecesarily. Win-win. The lesson from GPL vs BSD is that it is the restrictions in GPL that cause greater collaboration and growth of free software. The restriction to not take the code and run away with it. Frankly Tivo already picked linux despite the license and they probably would have done so anyway with a GPLv3-like no-DRM clause because they could build a cheaper box with it than with BSD, and cheaper than Replay TV licensees could. If they didn't, maybe we would all be using Replay instead (which imo is a much better dvr). If they did, we could still skip commercials despite industry pressure on Tivo not to. So I don't see how you can just say that not having some restriction is necessarily a 'win'. I think you are just assuming it would be a win because that aligns with your existing views. This is the 'just right' attitude that Linus and some kernel devs have that GPL2 just happens to be 'just right' -- as far as I have seen there's not really any justification for that. As of the "mainstream of the free software camp" (nice term, that one), well, that's funny, I think it's you, along with most FSF advocates, who are a bit disconnected from certain realities of the software world, particularly regarding competition against big software makers for the favor of the unwashed masses. But let's not argue about this. I am basing this on the discussions over GPL I have read, and talking to people at FSF and Red Hat, and other sources. This is why I posted my original message, because all the indication I have seen is that over time Linux kernel is going to be the odd-man-out, like BSD is today. It may still be 'the kernel' for a long time, but it's not going to be cool and the next generation of coders is going to ask why it's not "real GPL".
That sounds like what they are doing, improving performance by making more things native.
.NET bytecode is too complicated to run directly in a cpu).
.net, perl, ruby, smalltalk, and any number of other 'slow' languages that people are using anyway. The can add in a cell-like cpu who's only purpose is lzw-style compression or hashes, or these could be just *really* slow uninterruptible instructions only available on some cores... leaving others to handle interrupts and whatnot.
For example, they could put a Java bytecode interpreter "cpu" into the system. Java CPUs didn't take off because a mainstream processor would always have better process and funding, and you had to totally switch to Java. But if everybody had a Java "cpu" that only cost $0.25 extra to put in the chip and got faster as the main CPU got faster, then it might actually be useful (incidentally
Alternatively, they could put in generic garbage collection as a separate processor that runs all the time. This could accelerate Python, Java,
I don't think multi-threaded code is necessarily the only way to take advantage of multiple cores.
Maybe it's that GPLv2 happens to be an adequate common ground what seems to have made people like you believe, mistakenly, that you shared the Linux point of view. Just like it made people like me believe, also mistakenly, that I shared the FSF's point of view. For my part, I now realize that this is not the case. I also believe my point of view is the better one, of course.
That is a good description actually. In the past, people generally thought Linux (kernel) was free software when it now looks like Linux was just 'using' the free software camp to get ahead and did not really have any philosophical commitment to free software. It's clear that a large number of linux kernel developers are committed to open-source software not free software.
You mean that "early drafts" thing? I say that not because of the draft's rough quality but because they made me aware of the direction the FSF intended to take, the things they consider important. As I said, I mistakenly believed that I shared their convictions. That was a rude awakening of sorts. And yes, it was entirely my mistake. Like, for instance, somehow I misunderstood or disregarded Stallman's writings. My bad, won't happen again.
You basically said that it was the 'early drafts' that really woke you up to where free software was going and made you glad there was no upgrade clause in linux, but there has been a lot dropped out of GPLv3 since those drafts. I implied that to mean it was the content of the early drafts that your were upset about and not also what is in the latest version.
GPLv3 goes too far in its attempt to "protect the rights" of everyone. If someone wants to take my code and build a machine that doesn't boot modified software images, say a phone or some specialized portable device, as long as they release the source code I'm cool with that, but GPLv3 forbids it. If they want to write a client for SecondLife or some such, where the software bars the user from copying graphics or models or whatever, then they can't use my code either, because then they couldn't pursue patches disabling that restriction as "circunvention devices" under WIPO. Or so I think. Tell me if I'm wrong, because section 3 of the current draft is barely comprehensible
I think you forgot the clause "as long as I can still run the code on my own computers". It's not clear to me that market forces are sufficient to protect running any code we want on our own computers. I assume you are familiar with things like EFI which are part of a concerted effort to have DRM at every stage of the computer (most of which is already in place). That people cannot distribute GPL'ed software on such a machine without giving the ability to run modified software can only help to prevent this. In my opinion, section 3 pretty clearly states that you cannot use DRM that prevents the software from being modified. You could include DRM in hypothetical SecondLife client, but anybody could just compile it out again or modify the software to bypass it.
Anyway, that's another gripe I have: this new license is written in Legalese, rather than English. I think for J. Average Hacker is obscure and in parts plainly incomprehensible, like section 3 or section 6 of the current draft. ... The GPLv2 is clear, simple, and has never been challenged in court, afaik. So what's the problem again?
I find the GPLv2 vague and ambiguous in many ways. While it is longer and more detailed, I find GPLv3 easier to understand when I have a particular question (ie is this allowed by license?). From what I have read of the comments I also understand that it has corrected a number of deficiencies (such as expiration, warning periods, etc). So I have to disagree with you on this.
But Linux is not GPLv3, so we'll never know. However, Sun can choose to release under GPLv3 to be the FSF's "good guy", but alienating Linux developers in the process; or it can release under GPLv2 ("or later"
Right. But that's no different than the CDDL. Right now, to use ZFS you have to be able to glue a chunk of CDDL code into your project. Linux can't use it because of the GPL (any version). Shouldn't we, by your reasoning, say that that's Linus' fault for choosing the GPL instead of something else?
CDDL did not exist at the time, so it was not even a choice. Supposing it did, it is an open source license rather than a free software license, so comparing choice of CDDL vs GPL is a philosophical choice rather than an 'implementation' choice. So to answer your question, no we should not.
Linus is now preemptively blaming Sun for releasing ZFS under GPLv3, if they do, which would mean that Linux can't use it. What I am saying is that, like the bitkeeper fiasco, choosing to use *only* GPLv2 now looks like a big short-sighted mistake. And that this was Linus & Co's decision not Sun's.
Well, that's your perception. The short-sighted mistake, I mean. To me, it was a sensible choice. If you care about how people use your code, then you don't leave a backdoor for third parties to relicense your code as they see fit. Not even the FSF.
Well would you reasonably expect GPLv2 to be the last word on free software licenses? Would you expect people to never start using later version of GPL? You can in essence say 'well we want to have ultimate control over our code', which is what I said in my previous post, but not having an upgrade path is just poor planning. For example, code submitters could be able to opt-out of a license change Linus wanted to make -- that gives you the same rights to not have your code license changed but would allow Linux to easily get to GPLv3 but still only if it were generally acceptable to the developers at large.
In fact, and this will sound trollish, and I do apologise for that, but after reading the GPLv3, particularly the early drafts, I have to qualify: especially not the FSF.
I find this ironic because if you judge Linux by its rough drafts (early versions) then a lot of the code is simply a joke. It certainly did not come out of the ether fully formed. Many would have called the process used to develop it all manner of derogatory words, but what matters is what the results are. And GPLv3 looks to be much better than GPLv2 in a lot of ways; the process works.
Is anybody seriously saying Sun should release their code under the soon to be out-of-date GPLv2 simply because Linus 'likes' GPLv2 better? That's pretty absurd, and I assume you would agree.
I'm really sorry for being difficult, but no, I would not agree. C'mon, I keep reading GPLv3 advocates saying as much: GPLv2 is not going anywhere, you are as free to use it as you are to choose GPLv3. Now, regardless of how things got the way they are, or whose "fault" was it, Linux is GPLv2, and it doesn't seem likely that that will change anytime soon. Sun can choose GPLv2 if they want. In fact, I think there's a good chance they'll do precisely that, just so they can use the drivers.
I have read the comments and followed the evolution of GPLv3. There are a lot of good changes that are sometimes not obvious without explanation, such as adding an expiration so the license is more solid in some countries. Or removing ties to U.S. law, or using words that do not already have an established legal meaning. Or clarifying what a covered work is. And so on.
Sure, Sun can license their code using GPLv1 or GPLv2, but why should they use a license with known problems? Like you say it may be been done on purpose so that Linux cannot use the code, but by being limited to GPLv2 linux is giving Sun this opportunity to be the good guy -- looking at it objectively and independently Sun using GPLv3 is not just supporting free software but actively advancing it. If linux had some way to use GPLv3 then if your cynical theory is correct
GPLv3 actually helps Sun to have their codebase as the defacto standard, because any implementation would have to be based on Sun's code. And the definition of based on means that it would require the copyright permission, which means that any such work would also be under GPLv3 (and possible also other compatible licenses). In other words, if it doesn't have any of Sun's code in it then it isn't 'based on' Sun's ZFS and so doesn't have patent protection. First, the kernel devs (not only Linus) chose GPLv2 because they liked it. They don't seem to like GPLv3, so removing the "later version" language was evidently a prescient and wise move. Ultimately Linus (and whoever else) made the choice to use GPLv2 and only GPLv2. Linus is now preemptively blaming Sun for releasing ZFS under GPLv3, if they do, which would mean that Linux can't use it. What I am saying is that, like the bitkeeper fiasco, choosing to use *only* GPLv2 now looks like a big short-sighted mistake. And that this was Linus & Co's decision not Sun's. Is anybody seriously saying Sun should release their code under the soon to be out-of-date GPLv2 simply because Linus 'likes' GPLv2 better? That's pretty absurd, and I assume you would agree. Now, if Sun actually steps ahead and does it, I will gladly take back all this, apologise, and run to the kitchen to get some Tabasco for my nice plate of crow. And I will enjoy chewing on it, because it would be great to have ZFS. But, like Linus, I won't hold my breath waiting for that to happen. If Sun actually does release ZFS under GPLv3 Linux developers and users won't be enjoying that crow because Linux will still not have it in the kernel. It'll have a FUSE only slow version or have a legitimate patent cloud hanging over it. The existing FUSE ZFS would also have a patent cloud over it until they base it on Sun's implementation and thus release it under GPLv3 license.
Finally, you poo-poo software patents. I don't actually have a problem with software patents, what I have a problem with is bogus ones (one click, FAT32, etc) and patent trolls (patents owned by those who did not create them). It seems to me that there may be some actual non-obvious and new ideas in ZFS and if so then Sun should be rewarded in some way for coming up with them.
What we see here is Linux already starting to be held back by requiring what will be an older out-of-date license and Linus already starting to blame others for it, when with his stewardship it is his choice that caused it. Linux can't use a GPLv3 ZFS because Linus is against using the GPLv3 license. Linus removed the "or later version" clause because he wanted more control over the kernel. The only question is how stubborn and obstinate Linus will be before he decides to support GPLv3, and how much will that hurt Linux.
Really?
NTFS has data checksums to detect and repair corruption caused by any component?
You can add and remove disk space from an NTFS volume dynamically?
NTFS does data-level journaling not to mention without the overhead of multiple writes of the data?
NTFS can use compression without getting horrible fragmented or other negative side effects?
NTFS snapshots do not affect performance of the normal system?
NTFS has variable block sizes?
NTFS is open source and took less than a decade to get support on multiple systems?
As far as I know that's a big no on all those. I mean NTFS is very complex and has a lot of bullet points, but to claim that ZFS is just 'ntfs with larger address space' is really missing the boat.
"However, after I take a snapshot of a volume, the write performance to the original volume is
degraded by about 5 times. Why such a big degrade?"
"The advice seems to be to take the snapshot, mount it, copy the data off, and remove it as quickly as possible."
If you are using LVM snapshots for making a Time Machine you might as well do your video editing in vmware and use their snapshots. Either way it's going to be slow as hell. ZFS snapshot and LVM snapshots are worlds apart.
Are you kidding? This is ZFS we're talking about.
/video that is striped and ultra-fast whereas /home is mirrored and fault-tolerant.
ZFS is several orders of magnitude better at streaming large files like are used in video editing, which is already a huge draw for Macs. Since it is copy-on-write, writes are done without seeking so are very fast and can be spread out across multiple drives in parallel. IIRC within a zfs pool (collection of drives) you can make different 'filesystems' mirrored or striped, so you can have a
You can take your 100gb video and instantly say 'snapshot this' then make any number of changes to it and if you don't like it just revert back again. Contrast to every other filesystem (besides spirolog) where you have to make a 100gb copy as a backup -- which takes forever, so nobody does it unless they have to.
You can drop in a new drive and say 'use this drive' and your existing filesystem instantly has more space available and it is more fault tolerant or faster or both. If you want to remove a drive you say 'dont use this drive' and you can still use the OS normally while it moves data off to other drives.
Something like ZFS, that "touches so many other applications and parts of the OS" has to be the default. Otherwise you have to support two completely different ways of using the system. And that bloat and complication costs a lot more than just getting it right through extensive testing. If you are really worried about it, don't upgrade the OS for a while.
But that's the problem with subversion... the things that one might normally do all the sudden are 'fiddling with stuff you are not supposed to fiddle with' and a big 'no-no'.
/tmp
/other/file.c file.c
1) You want to make a copy of trunk to send to somebody:
tar cvf project.tar .
With svn you have to go through a bunch of magic to do this or you end up giving them an original copy when you may have local changes (you tweaked some config option or whatever), your username, time svn repo address and structrure, etc. If you do svn export it makes a copy of what is in HEAD not in your folder, so there is no way to do this without going back and weeding out this junk
2) You want to export something
# svn export svn:something
svn: '/tmp' already exists
Really, you think?
3) You make a copy of a file and then decide to rename it (or other cases).
# svn cp
# svn mv file.c newname.c
svn: Use --force to override
svn: Move will not be attempted unless forced
# svn --force mv file.c newname.c
svn: Cannot copy: it is not in repo yet; try committing first
Svn says you *must* do a bogus commit because you wanted to rename a file, or alternatively you can revert the new file and lose it? wtf? dumb.
4) You want to do the same thing on lots of files
# svn mkdir newdir
# svn cp *.c newdir
svn: Client error in parsing arguments
That's right you have to break out your bash/perl script skills to do this. Lame.
There's a *lot* to dislike about svn. It's basically just 'icky' all throughout. The checkouts are huge and ugly, many operations are slow (compared to monotone), its really annoying to have a private repo that you sync occasionally so you end up with zillions of tiny commits or losing work because you didn't commit enough. And the repo itself is very large -- converted a 2g repo from svn to monotone preserving revisions and even with straight add/del instead of renames/moves the monotone database was a small fraction of the size, about 1/6th. Incidentally, the monotone version was much faster in pretty much every way.
Monotone is technically much better than subversion, except for one problem that you can't checkout only a subset of a repo. Maybe they have fixed that by now and if so it would be crazy to use svn instead of it IMO. I'm sure there are also many others out there better than svn.