You need to turn off your ethics for a minute and think only about maximizing Microsoft's position. Clearly Microsoft would benefit enormously if they can make it so that OpenOffice doesn't officially comply with its own standard file format -- the main reason anybody even cares about a standard is so that governments and localities have a check box that makes it 'ok' to use OpenOffice.
Imo Microsoft wants to move the standard to ANSI then because that process is easier for them to manipulate into adding unnecessary complications and impossible requirements. This will put OO on a treadmill trying to support their own standard and Microsoft get to say "See, OO doesn't implement halting problem either, might as well buy from us because Office is more compatible with Office."
How do you lick your tongue? And why would you wipe your shirt? It's obviously a machine translation from some asian language, probably Chinese. This arrangement of the four characters, Lick Tongue Wipe Shirt, actually means "screen clearing by licking your shirt then wiping the screen with the wet area". Not to be confused with Lick Tongue Wipe Shorts... which means something entirely different.
This is why these languages make zero sense to many Westerners, and why they often end up five dollah poorer when they visit.
People who think first-to-file is a 'poorly though-out' idea I think generally look at it from the perspective of little-guy vs megacorp instead of by country:
First to invent is the method that favors countries that do a lot of invention, since anybody that steals the idea can't really get as much out of it.
First to file favors the countries that do more stealing of invention (china and russia as prime examples).
So I wouldn't write off the U.S. changing to first-to-file since it seems likely given the populations and education trends that usa will soon be more on the stealing side. F2F is probably a good thing overall unless we want to, oh I don't know, fix our education and social problems instead.
And when it is written down we call this punctuation.
The problem I have with the examples are that they are really easy to read aloud, either in one's head or vocally, but very difficult to read fast without actually verbalizing the script. Some of the research notes support this view:
After several students requested to read the syntactically formatted textbooks aloud in a low voice, and were permitted to do so, a majority of students elected, at least from time to time, to read these texts aloud. Although poorer readers in the VSTF group would read aloud regularly, one-fourth of the students in the VSTF group preferred to read silently and alone. This request to read aloud never emerged from the control groups, who, by contrast, generally resisted or declined reading aloud. In other words, the VSTF format seems to be geared toward verbalizing the sentence, either in one's head or vocally. That makes it good for 'slow' reading for facts in complext texts, like all of their tests were (college and high school textbooks), but maybe not good for speed reading esp where the exact content doesn't matter (harry potter).
You can put a world-renowned chef in a sewer and have him cook an omelet, but people are still going to vomit all over it. If microsoft programmers feel like they are being disparaged unfairly they need to get out of the sewer or clean it up.
If you think it's good, just say it. And that's exactly why I wrote that way, because if somebody interpreted my post as you did as supporting monad that would be very wrong. I do believe the idea of passing objects through pipes has some merit though.
On the other hand, a monad version of/bin/sort could just call the toString on all the objects and sort them based on that. Or it could sort on any other method you gave it, for instance:
Sort by name:
du -x / | sort --method 'toString'
Sort by size:
du -x / | sort --method 'getSize'
Also you could do things like make your own output formats without having to use/bin/cut and guess at what the right columns are going to be. If the commands are set up to take closures you could send them little 'scriptlets' that hook in to what the basic command does.
Look I'm sure Microsoft screwed it up so it's stupid since they basically screw up everything they do. But the actual idea behind it doesn't have to be as bad as your rant. Especially since you can always convert any object to a string and then are you back to unix.
Now they are even copying Java's "free but can't include it with your distro" licensing scheme. Only they have 'improved' on it by adding in bans on benchmarking and, oh yeah, you can't use it on Linux. And you can't even use your code with mono if you develop it with Microsoft's CLR.
So basically this is exactly like every other feature they ripped from Java and then pissed on.
Probably because instead of the banned strncpy Microsoft are using strcpyEx, which includes an extra parameter "iAllowDeny". When set to 1, this prevents buffer overflows. But because of the unfortunate name, some programmers think it will 'allow' exploits so they set it to 0.
If only Microsoft would add a C++lippy to MSVC to clear up these kinds of things.
Firstly, C# currently does not support covariance. You cannot treat a LinkedList of Integers as a LinkedList of Numbers (they are two incompatable types) -- if you could, then the method could add a Number to a list of Integers which would be wrong So in other words C# doesn't have real generic types *and* it has broken inheritance? For instance you can't refine a method taking Map<Number> in a subclass to be one taking Map<Integer>, where Integer inherits from Number? That sounds pretty broken to me, and judging by the message boards I'm not alone.
And no, you couldn't add something besides an integer to a list of integers after casting to a list of numbers because that's why type enforcement is for. Duh.
typeof(List{string}) != typeof(List{object} You call this generics when that holds but "List{string} instanceof List{object}" is false? C# generics are bullet points.
You don't know what you're talking about.... Admit it. You just completely made that up.... Total hogwash....considering how totally uninformed and made up your post was. Note that I was talking about CLR not C#, so it it you who are confused. CLR supports covariant and contravariant generic types, see Eiffel CLR for instance. Are you trying to say that it uses different optimizations when the code doesn't use these? That's fair, if true. CLR must be a seriously complicated machine to be able to support all of these uses in the same program. It's no wonder then that it isn't doing the advanced optimizations (CLR often can't even inline one method let alone several deep like a JVM does... see Eric's blog posts on this subject).
What you are missing is that it's a *good* thing that Java generics are not "real" generics.
With "real" generics the system has two choices: either generate lots of bloated specific instances of the code, or add type-checking at runtime. CLR designers thought they were going to do the former and it was going to be 'uber leet' and fast, but found out it's not practical (most of the optimizations that C++ uses to limit bloat do not apply well in a dynamic language) so they got stuck with the latter, for objects.
In Java, the code goes to add something to a generic list for example and it does one cast to the generic parameter type. Many times it can completely remove this check since it already knows from flow that the type is compatible. CLR can do this too, but only if it *also* knows the specific instance of the list (what the generic parameter types are), so it can remove fewer checks. This makes optimization harder as well since each use of a generic parameter can potentially block inlining and/or hoisting.
On top of that, the tests CLR has to do are *much* slower since they have to check many parallel type hierarchies (one per generic type references). For example, when passing a LinkedList of Integers to a parameter of type List of Numbers CLR has to in effect check both List assignable from LinkedList and Number assignable from Integer.
So in the vast majority of code not only do you end up with more checks but slower ones, and CLR has to maintain a complicated hierarchy of instantiated types to optimize this. All so primitives can be used faster in some cases, which is pretty ironic since in my experience these cases are usually easy to optimize by hand to use an array or patch out to inline C++ or JNI'd code.
In other words they messed up their runtime for bullet points without considering the implications. Not even to mention that in Java if you don't like generics, you just don't use them.
Re:Why do this?
on
AMD's New DRM
·
· Score: 2, Interesting
...we have perfect freedom of religion...
Having "In God We Trust" on our currency and "Under God" in our Pledge is not perfect freedom of religion. In America we have perfect freedom of religion, what we are missing is freedom from religion. And ironically only god has the power to give us freedom from religion, by suicide, but unfortunately he doesn't want to take the chance of going to hell.
Yes apparently god's immortal soul is more important than our utopia. What a self-centered mofo. Jesus died for us, why won't god?
In more than 16 years of doing MS programming and chasing the latest thing to keep ahead, I look back and wonder how many projects might still be in use if they were in Linux/Unix. I still get email occasionally from people who dig up some little program I wrote for unix 12 years ago. Sometimes they find it from USENET, sometimes just floating around the net someplace, and then they go to the trouble of searching the net to find my current contact just to say 'thanks' or to let me know that it works on whatever linux distro on amd64. The systems they were written for are now long-dead.
The Unix standards are just better than many others. They are simpler and more elegant, and they last a long time. On a cross-platform project I was working on recently some windows developer changed "uint32_t" to a "typedef DWORD UINT32_T" and "typedef uint32_t UINT32_T". Wtf is a DWORD and why not typedef it to uint32_t. I believe doing too much Windows programming warps even the best programmers; you either move on to something else or you lose the ability to write good code.
True, but the problem with x86 and ia64 is that the compression scheme is tied to the instruction set. It can't be substantially updated, improved, replaced, etc without recompiling programs. Better would be to separate them...
Each 4k page of code is compressed with whatever scheme is supported by the processor. The first byte indicates compression algorithm for the block or 0 for no compression (this byte is skipped over like a nop when executing sequentially from one block to the next). The block can't decompress to >4k, so many block will only be say 50% full. This saves on memory bandwidth even more than x86 and it is upgradable. If you want to save memory size too, each page can decompress to >4k and each jmp takes an address that is 50 bits of page address and 14 bits of offset into the decompressed page; we went to 64 bits to address data anyway not code. Then you get bandwitdth and in-core savings.
The CPU in some cases may have to fetch and decode a whole block just to run a 10-byte functions. So it could be an exceptionally bad idea, but I think compilers can learn to lay things out to minimize this (sounds like RISC...).
Now with this draft you can designate a proxy who can upgrade the license with a public statement. So contributors could say "GPLv3 or later versions approved by Linus". No wonder he likes this version.
I contend that 'credentialed' experts are not the driving force behind the articles in Wikipedia. It is the layperson, the mildly-knowledgeable, and the fanatics that actually write and maintain the vast majority of content. Experts *might* come in and tweak some information or possibly start the occasional article in their area, but their presence is minimal and not sufficient for verification.
People that talk about accountability and experts and reputation and such want to know the information is 'correct' so they come up with ideas like 'well just let the experts take care of it'. But why are the so-called experts going to do this for them? Who is going to sign off on an article and put their rep on the line unless they know for sure that every fact in the article is absolutely correct or they verify every fact? The more expert they are the less likely they are to risk their rep signing off on some random article in their field.
What it boils down to is for experts to have any meaningful role besides being a normal contributor the article has to be vouched for at some point (ie lots of work) and stay vouched for, so the rate of change cannot exceed the amount of time that experts will devote to the article. And I contend that experts are not going to put in anywhere close to the amount of effort needed to keep articles up-to-date.
Before making any 'expert only' kind of changes it would be nice to do a scientific study on wikipedia articles and see how much experts actually contribute and surveys to find out how much more they say they would contribute if they got props from it.
For instance I actually have a desktop system that draws 50 watts at idle, with two drives drives and a case fan (according to kill-a-watt...). If a different processor family takes 10 watts more you may call that academic, but I call it 20% more.
the actual user experience is with the whole platform, so I think it's appropriate to benchmark the power draw of the platform. That's exactly the point... virtually nobody is going to use their same configuration of 700W power supply, drive, memory, MB, CPU, video. So there is no user experience with these systems. It's almost entirely meaningless to give a power usage for them. And somebody building a low-power system still has no clue whether it's the Core processor that draws more, or the Intel motherboard that draws less, or the nvidia chipset that draws more, or how much the heatsink fan draws, etc.
Apparently you've never put together a low-power system, because you don't just try random combinations and see what the end result is... you look at individual components and find low-power combinations that work well together.
Any good review should actually measure the system power between wall socket and PSU, otherwise it's not really informative to the actual concerns of the user. Well if you RTFA that's exactly what they did, but it's wrong. You don't measure the power consumption of a processor by comparing the total system draw unless the systems are otherwise the same (you can compare Intel to itself this way, not to AMD). The Core motherboard they tested is from Intel and has aluminum heatsinks, whereas the motherboard for AMD was by Asus and had heat pipes. Maybe they just put heat pipes on for look, but my bet is this MB adds quite a bit to the system power use.
The difference between most systems they tested was between 1 and 16 watts, so it's almost a certainty that the CPU was drowned out by the difference between motherboards. Judging by this benchmark it's a good bet that the AMD chips (with the exception of the quad ones) themselves draw significantly less power when idle than Core.
They could at least subtract out known power like drives, graphics card (use a low power one for doing the power tests), system fan, maybe processor fan, etc. Maybe turn the system on with no processor installed and use that as a baseline (if that doesn't destroy the system I don't know).
The problem with squashfs is that it doesn't work on a generic unix (so darwin, bsd, hurd portage would be irritated or split). It also is a dependency on the particular kernel features, and it's complicated to set up (mounting, unmounting, losetup, etc).
Python seems to have "zipfile" built in as a standard library, and pretty much everything else can read/write zip files in some way. They are rsync and search friendly. They use existing filesystem concepts (file/path). Users can still hack the repo, where a sql or berkeley db would be much harder. It's a little harder to write back to them or call some external program like say grep, but this doesn't sound like a problem for using them in portage.
Informing the user that some URL might be something different from what they thought it was supposed to be so that they can hopefully recognize fakes is just plain stupid. It relies on people interpreting information and people make mistakes, so a phisher just keeps trying until somebody messes up. Plus, it presumes excellent eyesight... some people can't really tell an 'o' from a 'e' in a normal English font, either from bad eyesight or bad monitor or both. Some people can't tell a 'b' from a 'd' due to dyslexia. But I guess it's okay for those people to get their information stolen??
The solution is to not have users type in their information all the time.
Client certificates. When you register your account the first time with some site you get a certificate that your browser has to use each time you visit the site, or you can't get in without say actually calling the business to get one. The user never types in their login / password again (certificate contains their name or id number). Now user goes to a site and it says 'dude we need your password again' when it hasn't asked for that in 5 years and they get suspicious or better yet their password expired 10 days after they received it and they *can't* give the phisher access.
The only change for this to happen is for sites to actually use client certificates with SSL and for the browser and other software (hotsync, etc) to make this easier and... problem solved.
Thanks for assuming I wouldn't have done that already. I have portage, edb, db, and/usr/tmp linked to a reiserfs. You know what? It's still really bad, although on the other hand it is much better than keeping it all on the main fs.
I tried using reiser4 as my main fs and would get 10+ second freezes. Maybe it's good for only doing portage, but I wouldn't know. No thanks.
From a basic knowledge of python it looks like it should be pretty easy to intercept the standard open, read, write, close calls to first look in a portage.zip and then fall back to/usr/portage (or vice versa). I bet this problem could be solved in a day by a skilled python coder.
Seventy percent of the files in my repository are from subversion overhead. They used to even store a file called "zero" which was a zero-byte file under every svn-controlled folder. Over half the space is taken up by local copies (1.5g) even though I am on gigabit ethernet and haven't once done a 'svn revert' on the entire repository... but if I did it sure would be fast. Meanwhile the main benefit of local copies (fast diffs and status) is broken because if you edit/replace a file in 1 sec after doing an update then svn may completely ignore the changes. And yes this actually happened to me... build new binary -> svn update -> copy binary into svn tree -> svn ignores it.
It's no wonder they of all people should be giving a talk on how to deal with malcontents. Monotone may also have some problems of its own, but at least they get these things right and have a different approach. Subversion's claim to fame is that it is 'slightly better than CVS'. That makes me angry. I just wish next time they could give a talk on writing good software.
Right now there are 220,000 files, some ~100 bytes and others ~0-4k. Just to support portage. Space-age filesystems or not that's a lot of tiny files to be scattered around and updated piecemeal. What happens is that gentoo starts taking more and more time to do syncs and searches, not to mention everything else slowing down.
A good solution would be to put portage into a.zip file. In a zip each file is compressed individually, so you could still do rsync diffs. There's an index at the end so you can do really quick lookups (bypassing the whole slow path of inode / namei). The fs can do read-ahead and caching much better on a single file, and it won't have to do a seek for every file.
This is the kind of real, fundamental problem that gentoo should be solving. Gentoo should be the lightest distro, not a huge sprawling mess.
Who invented the idea of an integrated disk read cache? Nobody knows because it's such a trivial idea that claiming credit for it just makes you look silly -- and desperate. If Microsoft is so stretched for innovation that they have to go around demanding props for "hey lets write these 100 bytes to flash instead of spinning up the drive" then they are in really bad shape. My advice is to jump ship now before the MS Titanic hits a penguin.
Slashdot Mirror
Each profession gets an epic 375 level pattern to combat profanity:
...
Alchemy: Epic Bar of Soap
Blacksmith: Hammer of Respect
Mining: Mote of Censorship
Enchanting: Greater Moral Power
On Equip: Opponent cannot decline a duel
Then these holy warriors can run around town doing something proactive against all this blasphemy.
You need to turn off your ethics for a minute and think only about maximizing Microsoft's position. Clearly Microsoft would benefit enormously if they can make it so that OpenOffice doesn't officially comply with its own standard file format -- the main reason anybody even cares about a standard is so that governments and localities have a check box that makes it 'ok' to use OpenOffice.
Imo Microsoft wants to move the standard to ANSI then because that process is easier for them to manipulate into adding unnecessary complications and impossible requirements. This will put OO on a treadmill trying to support their own standard and Microsoft get to say "See, OO doesn't implement halting problem either, might as well buy from us because Office is more compatible with Office."
This is why these languages make zero sense to many Westerners, and why they often end up five dollah poorer when they visit.
People who think first-to-file is a 'poorly though-out' idea I think generally look at it from the perspective of little-guy vs megacorp instead of by country:
First to invent is the method that favors countries that do a lot of invention, since anybody that steals the idea can't really get as much out of it.
First to file favors the countries that do more stealing of invention (china and russia as prime examples).
So I wouldn't write off the U.S. changing to first-to-file since it seems likely given the populations and education trends that usa will soon be more on the stealing side. F2F is probably a good thing overall unless we want to, oh I don't know, fix our education and social problems instead.
The problem I have with the examples are that they are really easy to read aloud, either in one's head or vocally, but very difficult to read fast without actually verbalizing the script. Some of the research notes support this view: After several students requested to read the syntactically formatted textbooks aloud in a low voice, and were permitted to do so, a majority of students elected, at least from time to time, to read these texts aloud. Although poorer readers in the VSTF group would read aloud regularly, one-fourth of the students in the VSTF group preferred to read silently and alone. This request to read aloud never emerged from the control groups , who, by contrast, generally resisted or declined reading aloud. In other words, the VSTF format seems to be geared toward verbalizing the sentence, either in one's head or vocally. That makes it good for 'slow' reading for facts in complext texts, like all of their tests were (college and high school textbooks), but maybe not good for speed reading esp where the exact content doesn't matter (harry potter).
On the other hand, a monad version of /bin/sort could just call the toString on all the objects and sort them based on that. Or it could sort on any other method you gave it, for instance:
/bin/cut and guess at what the right columns are going to be. If the commands are set up to take closures you could send them little 'scriptlets' that hook in to what the basic command does.
Sort by name:
du -x / | sort --method 'toString'
Sort by size:
du -x / | sort --method 'getSize'
Also you could do things like make your own output formats without having to use
Look I'm sure Microsoft screwed it up so it's stupid since they basically screw up everything they do. But the actual idea behind it doesn't have to be as bad as your rant. Especially since you can always convert any object to a string and then are you back to unix.
Now they are even copying Java's "free but can't include it with your distro" licensing scheme. Only they have 'improved' on it by adding in bans on benchmarking and, oh yeah, you can't use it on Linux. And you can't even use your code with mono if you develop it with Microsoft's CLR.
So basically this is exactly like every other feature they ripped from Java and then pissed on.
Probably because instead of the banned strncpy Microsoft are using strcpyEx, which includes an extra parameter "iAllowDeny". When set to 1, this prevents buffer overflows. But because of the unfortunate name, some programmers think it will 'allow' exploits so they set it to 0.
If only Microsoft would add a C++lippy to MSVC to clear up these kinds of things.
And no, you couldn't add something besides an integer to a list of integers after casting to a list of numbers because that's why type enforcement is for. Duh. typeof(List{string}) != typeof(List{object} You call this generics when that holds but "List{string} instanceof List{object}" is false? C# generics are bullet points. You don't know what you're talking about.
What you are missing is that it's a *good* thing that Java generics are not "real" generics.
With "real" generics the system has two choices: either generate lots of bloated specific instances of the code, or add type-checking at runtime. CLR designers thought they were going to do the former and it was going to be 'uber leet' and fast, but found out it's not practical (most of the optimizations that C++ uses to limit bloat do not apply well in a dynamic language) so they got stuck with the latter, for objects.
In Java, the code goes to add something to a generic list for example and it does one cast to the generic parameter type. Many times it can completely remove this check since it already knows from flow that the type is compatible. CLR can do this too, but only if it *also* knows the specific instance of the list (what the generic parameter types are), so it can remove fewer checks. This makes optimization harder as well since each use of a generic parameter can potentially block inlining and/or hoisting.
On top of that, the tests CLR has to do are *much* slower since they have to check many parallel type hierarchies (one per generic type references). For example, when passing a LinkedList of Integers to a parameter of type List of Numbers CLR has to in effect check both List assignable from LinkedList and Number assignable from Integer.
So in the vast majority of code not only do you end up with more checks but slower ones, and CLR has to maintain a complicated hierarchy of instantiated types to optimize this. All so primitives can be used faster in some cases, which is pretty ironic since in my experience these cases are usually easy to optimize by hand to use an array or patch out to inline C++ or JNI'd code.
In other words they messed up their runtime for bullet points without considering the implications. Not even to mention that in Java if you don't like generics, you just don't use them.
...we have perfect freedom of religion...Having "In God We Trust" on our currency and "Under God" in our Pledge is not perfect freedom of religion. In America we have perfect freedom of religion, what we are missing is freedom from religion. And ironically only god has the power to give us freedom from religion, by suicide, but unfortunately he doesn't want to take the chance of going to hell.
Yes apparently god's immortal soul is more important than our utopia. What a self-centered mofo. Jesus died for us, why won't god?
The Unix standards are just better than many others. They are simpler and more elegant, and they last a long time. On a cross-platform project I was working on recently some windows developer changed "uint32_t" to a "typedef DWORD UINT32_T" and "typedef uint32_t UINT32_T". Wtf is a DWORD and why not typedef it to uint32_t. I believe doing too much Windows programming warps even the best programmers; you either move on to something else or you lose the ability to write good code.
True, but the problem with x86 and ia64 is that the compression scheme is tied to the instruction set. It can't be substantially updated, improved, replaced, etc without recompiling programs. Better would be to separate them...
Each 4k page of code is compressed with whatever scheme is supported by the processor. The first byte indicates compression algorithm for the block or 0 for no compression (this byte is skipped over like a nop when executing sequentially from one block to the next). The block can't decompress to >4k, so many block will only be say 50% full. This saves on memory bandwidth even more than x86 and it is upgradable. If you want to save memory size too, each page can decompress to >4k and each jmp takes an address that is 50 bits of page address and 14 bits of offset into the decompressed page; we went to 64 bits to address data anyway not code. Then you get bandwitdth and in-core savings.
The CPU in some cases may have to fetch and decode a whole block just to run a 10-byte functions. So it could be an exceptionally bad idea, but I think compilers can learn to lay things out to minimize this (sounds like RISC...).
Now with this draft you can designate a proxy who can upgrade the license with a public statement. So contributors could say "GPLv3 or later versions approved by Linus". No wonder he likes this version.
I contend that 'credentialed' experts are not the driving force behind the articles in Wikipedia. It is the layperson, the mildly-knowledgeable, and the fanatics that actually write and maintain the vast majority of content. Experts *might* come in and tweak some information or possibly start the occasional article in their area, but their presence is minimal and not sufficient for verification.
People that talk about accountability and experts and reputation and such want to know the information is 'correct' so they come up with ideas like 'well just let the experts take care of it'. But why are the so-called experts going to do this for them? Who is going to sign off on an article and put their rep on the line unless they know for sure that every fact in the article is absolutely correct or they verify every fact? The more expert they are the less likely they are to risk their rep signing off on some random article in their field.
What it boils down to is for experts to have any meaningful role besides being a normal contributor the article has to be vouched for at some point (ie lots of work) and stay vouched for, so the rate of change cannot exceed the amount of time that experts will devote to the article. And I contend that experts are not going to put in anywhere close to the amount of effort needed to keep articles up-to-date.
Before making any 'expert only' kind of changes it would be nice to do a scientific study on wikipedia articles and see how much experts actually contribute and surveys to find out how much more they say they would contribute if they got props from it.
1) Tom Bombadil is the personification of Neutral (ie he is switzerland).
2) Yes, but they are vestigial.
Apparently you've never put together a low-power system, because you don't just try random combinations and see what the end result is... you look at individual components and find low-power combinations that work well together.
The difference between most systems they tested was between 1 and 16 watts, so it's almost a certainty that the CPU was drowned out by the difference between motherboards. Judging by this benchmark it's a good bet that the AMD chips (with the exception of the quad ones) themselves draw significantly less power when idle than Core.
They could at least subtract out known power like drives, graphics card (use a low power one for doing the power tests), system fan, maybe processor fan, etc. Maybe turn the system on with no processor installed and use that as a baseline (if that doesn't destroy the system I don't know).
The problem with squashfs is that it doesn't work on a generic unix (so darwin, bsd, hurd portage would be irritated or split). It also is a dependency on the particular kernel features, and it's complicated to set up (mounting, unmounting, losetup, etc).
Python seems to have "zipfile" built in as a standard library, and pretty much everything else can read/write zip files in some way. They are rsync and search friendly. They use existing filesystem concepts (file/path). Users can still hack the repo, where a sql or berkeley db would be much harder. It's a little harder to write back to them or call some external program like say grep, but this doesn't sound like a problem for using them in portage.
Informing the user that some URL might be something different from what they thought it was supposed to be so that they can hopefully recognize fakes is just plain stupid. It relies on people interpreting information and people make mistakes, so a phisher just keeps trying until somebody messes up. Plus, it presumes excellent eyesight... some people can't really tell an 'o' from a 'e' in a normal English font, either from bad eyesight or bad monitor or both. Some people can't tell a 'b' from a 'd' due to dyslexia. But I guess it's okay for those people to get their information stolen??
The solution is to not have users type in their information all the time.
Client certificates. When you register your account the first time with some site you get a certificate that your browser has to use each time you visit the site, or you can't get in without say actually calling the business to get one. The user never types in their login / password again (certificate contains their name or id number). Now user goes to a site and it says 'dude we need your password again' when it hasn't asked for that in 5 years and they get suspicious or better yet their password expired 10 days after they received it and they *can't* give the phisher access.
The only change for this to happen is for sites to actually use client certificates with SSL and for the browser and other software (hotsync, etc) to make this easier and... problem solved.
Thanks for assuming I wouldn't have done that already. I have portage, edb, db, and /usr/tmp linked to a reiserfs. You know what? It's still really bad, although on the other hand it is much better than keeping it all on the main fs.
/usr/portage (or vice versa). I bet this problem could be solved in a day by a skilled python coder.
I tried using reiser4 as my main fs and would get 10+ second freezes. Maybe it's good for only doing portage, but I wouldn't know. No thanks.
From a basic knowledge of python it looks like it should be pretty easy to intercept the standard open, read, write, close calls to first look in a portage.zip and then fall back to
Seventy percent of the files in my repository are from subversion overhead. They used to even store a file called "zero" which was a zero-byte file under every svn-controlled folder. Over half the space is taken up by local copies (1.5g) even though I am on gigabit ethernet and haven't once done a 'svn revert' on the entire repository... but if I did it sure would be fast. Meanwhile the main benefit of local copies (fast diffs and status) is broken because if you edit/replace a file in 1 sec after doing an update then svn may completely ignore the changes. And yes this actually happened to me... build new binary -> svn update -> copy binary into svn tree -> svn ignores it.
It's no wonder they of all people should be giving a talk on how to deal with malcontents. Monotone may also have some problems of its own, but at least they get these things right and have a different approach. Subversion's claim to fame is that it is 'slightly better than CVS'. That makes me angry. I just wish next time they could give a talk on writing good software.
Right now there are 220,000 files, some ~100 bytes and others ~0-4k. Just to support portage. Space-age filesystems or not that's a lot of tiny files to be scattered around and updated piecemeal. What happens is that gentoo starts taking more and more time to do syncs and searches, not to mention everything else slowing down.
.zip file. In a zip each file is compressed individually, so you could still do rsync diffs. There's an index at the end so you can do really quick lookups (bypassing the whole slow path of inode / namei). The fs can do read-ahead and caching much better on a single file, and it won't have to do a seek for every file.
A good solution would be to put portage into a
This is the kind of real, fundamental problem that gentoo should be solving. Gentoo should be the lightest distro, not a huge sprawling mess.
Who invented the idea of an integrated disk read cache? Nobody knows because it's such a trivial idea that claiming credit for it just makes you look silly -- and desperate. If Microsoft is so stretched for innovation that they have to go around demanding props for "hey lets write these 100 bytes to flash instead of spinning up the drive" then they are in really bad shape. My advice is to jump ship now before the MS Titanic hits a penguin.