> advising students that they risk lost job opportunities
Strange. When I seek for jobs I worry much more about employers not knowing me enough rather than they know me too much. And no employer will be bored enough to actually read every message in your blog to find your "most silly moment" before he decides whether to hire you.
Because it doesn't fit the needs of the user. As a user, if I show a long page at 75% size, I expect the browser to use the full width to show more words in the page, rather than to show a page that fill use 75% of the screen width. And when I make the words small, I have no intention to make the images small.
> they make 100 billion if they sell you a pill over and over again, > preferably for the rest of your life or they make 10 billion selling > the cure. once eradicated from earth, that medicine will be > completely useless and not able to be sold.
No problem. Just like that you might get 100 billion if every computer is only of 8086 speed and people get to solve their problems, so they have to buy an insane number of computers. If you produce a Pentium 4, people might suddenly be able to solve many problem with a single computer, and they might only be able to earn just 10 billion.
> if you were a CEO with less than impeccable morals (CEO, financial > backer, etc) would you opt for the 10 billion with a clear > conscience or 100 billion
The wise CEO see something else: if another company does the research and starts wanna earn the 10 billion drug, and they are stuck with patent laws and can't produce any of those, they earn nothing. If AMD is selling their athlon 64 at the same price at a 8086 when Intel is selling it at exactly the same price, Intel is going to go out of business rather quickly.
I hate patents, but don't attack them with illogical conspiracies.
I do subscribe to LWN. Having to pay is not really a problem. Having to pay for useless content is, no matter whether the payment is done directly by having me keying in my credit card number, or indirectly by having me to view loads of crappy ads.
> "Anyone who's not a building contractor has no > business hanging a picture. Period."
No. But anyone who's not a building contractor really has no business taking down a wall in your house.
> "Anyone who's not a professional electrician has > no business plugging anything in. Period."
No. But anyone who's no a professional electrician really (should) have no business removing the front cover of your socket and swap a worn wire in it with a new one.
Anything has an internal and an external interface. I have no problem documenting the external interface: I do write doc comments or PODs. What I won't do is to write comments that essentially says "this internal function is there for doing this and this", because the internal function will be modified faster than I can write comment for it, and if it is so complicated that it really needs comments, it is too complicated anyway. I won't write comments that essentially says "this line of code is there so that this and this happen", because I think that the code should be written in a way that it is trivial to know this for any professional developer, and unless it is impossible to do it, I won't write such a comment. This is what I call a in-code comment.
As of programming, if you are still in an age where senior programmer will make all the design and your junior programmer will code it, it means you will always have bad design. Design comes from the coding, or actually the difficulty of coding. You are spliting up two very closely related tasks to two different people. The same for unit testing.
> I don't know why people (in general) don't like to > comment code.
I don't write in-code comment because I think writing comments is a horrible way of documentation. I'll prefer writing out-of-code overview documents of the whole set of code so that people (or the future me) will know where to look at for particular behaviour, and what are the general design. After that, it is all the code which serves as the definitive comment---unless there is no way to write code that are sufficiently efficient, clear and easy to maintain at the same time.
As for insufficient skills, those with insufficient skills to read my code has no business with my code. Period.
> I consider them to be nothing more than > tricks to get around the braindead > limitations of most mainstream object > oriented languages
This is a perfectly right comment. For example, if your language supports closure, your need of the command pattern is greatly reduced. If you use a dynamic language like Perl or Python, you will find many patterns like bridges and abstract factories completely useless.
That said, each language has its own set of limitation. Before some genius creates a language that has everything we want (and still has the language comprehensible), we will continue to need some "band aid". If we need band aids, it is probably better to have a standard band aid for each purpose, rather than having a different one each time for no reason.
Any language that supports closures fully can support that. Perl can, Javascript can, and Python can. Perl even have syntactic sugar (in particular, subroutine prototype) which makes it easier to define your own syntax (see how Error.pm does that). None of them are as fast as a compiled Lisp program, and none of them are as flexible (since you don't need to treat the closure as a black box in Lisp, whereas in Perl you can't see what is in the closure argument), though. On the other hand, if you see people who says "Java is a very developer-friendly language that allows you to code very rapidly", they are seriously mistaken.
> Just take a look at the fibonacci test - it > a stupid useage of recursion, if your > compiler doesnt optimize out all the > duplication
I think a good recursion test should be done only to a problem that really needs recursion, not toy problems like Fibonacci that you can do much better in other ways. And in such a test, those with compiler which tries to do funny things like automatic memoization will only get hurt. You can find a large set of such problems by just looking at the acm.uva.es archive.
In such a test, Python *will* be graded poorly. But then, Python is not about speed of programs. It's about speed of reading and writing programs. And when all are off, you can always implement the performance critical part in C or C++.
> Temperature is also more intuitive because > it is based on humans. 0 is cold, 100 is hot > so it is the relative feeling of temperature > rather than the scientific basis of water.
Scientifically, different human being perceives temperature differently, especially when the different individual lives in different part of your country. Do you prefer to have a different temperature unit for each of the states? (e.g., at my place the temperature never falls below 35F. I'd consider 50F already pretty cold. So your reasoning doesn't work for me at all.)
> That 20% difference in functionality and the > $700 premium that Adobe charges for it is > what separates GIMPers from Photoshoppers
I'll bet that at least 80% of the people using Photoshop actually use none of the 20% difference in functionality but pay the $700 premium anyway. On the other hand, this is a side issue, nothing to do with freedom. GNU followers, myself included, think that the lack of a fully modifiable and compilable source code of Photoshop makes a significant philosophical *and* practical difference, that we don't think Photoshop is a replacement to Gimp at all. Real GNU followers are okay to pay for software, but not okay if they are asked to conceal it from others.
> You can't convert people to your religion > by waving an AK-47 in their faces
I don't quite understand what act you are refering to. It seems to me that "waving an AK-47 in others' faces" is an act to threaten others that "if you don't follow our way I'll kill or significantly injure you". I don't see any act here with any similar effect. Perhaps I'm missing something.
If the world starts with no MS from the beginning, there will be somebody who take the field. Software is something that work best when many, many, indeed the majority of people are using exactly the same piece of it. In other words, a monopoly is the normal trend. On the other hand, that company may or may not tried to use nearly as many MS tactics. If not, then free software probably won't be nearly as popular as it is today: really not many people care about a few dozens of bucks or the inavailability of source code, but everybody can see now what world that closed world can lead us to.
On the other hand, what will happen if MS dies tomorrow for whatever reason, with all its assets destroyed? That would be extremely funny. Everybody who had been depending on MS software will suddenly find that their computers are facing a increasing tide of exploits, with nobody who can do anything about fixing them. Probably no sane person will look at any closed source software again. Unluckily (or luckily, depending on who you are), that is not going to happen.
If you don't need security, then simply dropping security support is much easier than installing some software to "pretend" to support it. I see no problem that FreeSWAN refuse to interoperate with anything that can't be made to be secure in the first place.
> Getting the Internet to change what's not > broken is very hard. The fact that our > default mode of communications is > plaintext doesn't quite scare most pointy > haired bosses. They want their stuff > secured, but there's no sense in switching > protocols when we can just secure on top > of the existing protocols with things like > VPNs, SSH, PGP, SSL, etc.
If you really look at it, those solutions are much more difficult and expensive to setup than freeswan in its finished operation mode, i.e., opportunistic encryption (OE). E.g., in PGP, what you need to do is to install an extension of your mailer, and you publish your public key, and your partner fetch your public key, and get an extension of her mailer, and finally she can read your mail while being happy that the mail is safe. Each party must get and verify the key of everybody quite "manually". On the other hand, OE would just have both parties post a key in the DNS server, install FreeSWAN and done.
> Meanwhile, getting the government to lift > the crypto-export bans just isn't going to > happen either. September 11th, 2001 will > always be brought up anytime anybody wants > to loosen crypto rules. Being able to talk > in a way that the US Government can't > intercept and understand is something that > truely scares the military and the CIA... > because if they can't intercept > communications, they lose one of their > strongest tools in battle. Maybe the > crypto-export rules are weak and aren't > going to stop much, but at least it stops > everything we can stop using a law, and > that's better than zero.
Probably no. By now it is completely infeasible for the government to restrict cryptography. Even if they do, no government can stop people from modifying RSA to use a 4096-bit key and use it to encrypt his super-secret, criminal, whatever message. And there is really no feasible way to break it. Cryptography is out there, and there is no way to stop. Better to learn the fact and live with it, rather than to try uselessly fight against it.
It seems to me that the primary reason that the project has to stop is the lack of funding. For OE to be usable, it should be made even easier, but there is no funds to make this possible. It's really sad that such good projects must end this way.
In fact, even in C it is possible to benefit from run-time information. In particular, branch probability can be estimated by compiling the program twice, once to ask the compiler to record how many times each branch is taken, and once to ask the compiler to use the stats obtained to generate code. See the -fbranch-probabilities and -fprofile-arcs options of gcc.
> The fact that it is all being stored in a > single block is bad, as reallocating and > copying that block as it gets larger will > take linear time, especially if you do > something stupid like reallocate on every > addition rather than predict the space > ahead of time. It is also possible that > ext is really stupid about adding to the > data structure, possibly rearranging the > names into the order of the tree, which > would cause the slowness you are seeing.
Sorry? We are talking about the directory, not files. How to pre-allocate? In any case a single block (1024 bytes, typically) does not have enough room to store the directory that I'm creating, which contains thousands of files! And what "data structure" you are talking about?! Do you have *any* knowledge about the ext2/ext3 filesystem?
> *Looking up files* in the directory takes > time that is approximately the log of the > number of files, indicating a tree.
Are you really sure? Did you ever tested your "theory"?
Lookup a non-existing file using ls in a freshly-mounted ext3 directory with N empty files created in advance, named 0, 1, 2,..., N-1:
> The filenames have to be stored somewhere, > you know.
In the directory, as a long, plain list. No B-tree, no hash table. Nothing to improve the efficiency, apart from the dentry-cache in the memory. But then, to access a directory still require the kernel to load the whole directory.
If you don't believe me, try an experiment: create a directory, try to create 100,000 empty files in it, and every 1000 files created you will print the current time. If the directory is implemented by a b-tree, the time taken should be about constant (actually, should be increased in the order of logarithm of the number of files within the directory). If, on the other hand, it is implemented by a list, you the time taken should be increased very steadily. My experiment shows the following:
00Thu Dec 11 14:30:35 HKT 2003 01Thu Dec 11 14:30:38 HKT 2003 02Thu Dec 11 14:30:41 HKT 2003 03Thu Dec 11 14:30:45 HKT 2003 04Thu Dec 11 14:30:50 HKT 2003 05Thu Dec 11 14:30:55 HKT 2003 06Thu Dec 11 14:31:00 HKT 2003 07Thu Dec 11 14:31:06 HKT 2003 08Thu Dec 11 14:31:13 HKT 2003 09Thu Dec 11 14:31:20 HKT 2003 10Thu Dec 11 14:31:29 HKT 2003 11Thu Dec 11 14:31:38 HKT 2003 12Thu Dec 11 14:31:48 HKT 2003 13Thu Dec 11 14:31:58 HKT 2003 14Thu Dec 11 14:32:10 HKT 2003 15Thu Dec 11 14:32:21 HKT 2003 16Thu Dec 11 14:32:34 HKT 2003 17Thu Dec 11 14:32:47 HKT 2003 18Thu Dec 11 14:33:01 HKT 2003 19Thu Dec 11 14:33:16 HKT 2003 20Thu Dec 11 14:33:33 HKT 2003 21Thu Dec 11 14:33:49 HKT 2003 22Thu Dec 11 14:34:04 HKT 2003 23Thu Dec 11 14:34:21 HKT 2003 24Thu Dec 11 14:34:40 HKT 2003 25Thu Dec 11 14:34:58 HKT 2003 26Thu Dec 11 14:35:17 HKT 2003 27Thu Dec 11 14:35:40 HKT 2003 28Thu Dec 11 14:36:03 HKT 2003 29Thu Dec 11 14:36:24 HKT 2003 30Thu Dec 11 14:36:47 HKT 2003... (I got bored waiting)
It shoulds the amount of time needed to create 1000 files grows steadily from 3 seconds to 23 seconds and has no sign to stop growing. Anybody with slight data structure knowledge should understand that there is not a B-tree or any efficient data structure underlying the ext3 directory.
You obviously don't have actually see a hex-dump of your ext3 filesystem. The directories *are* a sequential long list. There is a patch to use a hash, but the patch is not in the default stable kernel, yet.
Swap space is always extremely simple, much simpler than the FAT filesystem. It is not used to hold directories and files, so it has very little structure. All you need is (1) a signiture that tells it is a swap space; (2) a few parameters like what is the size of each block within the swap space, which is supposed to be the same as the page size, and the size of the whole swap space; (3) a list of "bad blocks" that must be kept unused, and (4) the actual data. You can read the man page of mkswap(8) in Linux to know the details.
> c++ isn't portable, normally. C++-- might be > though. Then again, it might not be. The > java language is very standardized; and in > case you shouldn't have a compiler on that > platform, the bytecode is too!
If you see non-conforming C++ implementation, you should go blame the compiler vendor, not the language. And Java is not standardized at all. C++ goes through the standardization process and now have ISO standards, Java has nothing about it. C# does have a ECMA standard as well, so Java is alone on the lack of standardization. Basically, Sun decide on it, and everybody has to follow. Now you can see why there are so many mis-features or lack-of-features in that language: it has never been beaten to death by vendors before it is set in stone.
> [OEMs] put it on computers because Windows > is the REASON that people buy the computers.
Most people buy computers because they want to do tasks like preparing and printing documents, browsing and using the web, sending, receiving, reading and posting E-mails and newsgroups, managing their bank accounts and their tax forms, creating presentations, getting, storing photos and movies they get from their digital cameras, etc. Windows is nearly never the "REASON" why people buy their computers. Instead people scold Windows when the work they want to get done gets in the way when Windows tell them that their applications has an error.
This is, of course, unless you equate preparing and printing documents with Microsoft Word, browsing and using the web with Internet Explorer, sending, receiving, reading and posting E-mails and newsgroups with Outlook Express, managing their bank accounts and their tax forms with Microsoft Money, creating presentations with Microsoft PowerPoint, getting, storing photos and movies they get from their digital cameras with Adobe Photoshop, etc. But then its the problem of the clueless user, not the problem of Linux.
This means that even if an application marks a certain memory area non-executable (by not providing the PROT_EXEC flag upon mapping it) under x86, that area is still executable, if the area is PROT_READ.
Does this statement imply that some x86 processors do the right thing with PROT_EXEC?
No. The x86 page table has 12 bits per page table entry for storing page information. It contains a bit for R/W (read/write) which you can force a page read-only; and it contains a bit U/S (user/supervisor) which you can force a page usable only by the kernel. There is nothing which says "this page must not be executed as code". So Linux kernel actually has an interface that only some hardware provides. I don't think now it still has spare bit to give for executable bit.
Furthermore, the x86 ELF ABI marks the process stack executable, which requires that the stack is marked executable even on CPUs that support an executable bit in the pagetables.
Does this statement imply that some x86 processors do the right thing with PROT_EXEC?
It is not about "do the right thing". The processor simply has no such bit, so there is no new "right thing" for it to do---it is already doing the right thing. The processor assumes that segmentation is used to enforce execute permission, so that each library code should be allocated a segment and inter-segment jumps and calls should be used to access them. In such way only read-only code segments are executable. Linux simply decided at the very beginning not to employ this facility.
If Linus is willing to create a new ELF standard, could this problem be fixed?
ELF is not designed by Linus. And even if ELF is changed so that stack is not assumed executable by default (which probably break some programs that rely on executable stack), all computers from 386 to P4 will not benefit from it.
The page is really helpful in understanding what TCPA is. However, there is one point that I don't quite understand. The Why TCPA document says:
The "trusted boot function provide the ability to store in Platform Configuration Registers (PCR), hashes of configuration information throughout the boot sequence. Once booted, data (such as symmetric keys for encrypted files) can be "sealed" under a PCR. The sealed data can only be unsealed if the PCR has the same value as at the time of sealing. Thus, if an attempt is made to boot an alternative system, or a virus has backdoored the operating system, the PCR value will not match, and the unseal with fail, thus protecting the data.
Fine, I can have data for my Linux partition that is unreadable even if my naughty sister boot a Windows XP on it. Seems something that I might want. Then later in the article, it says:
The TCPA chip is not particularly suited to DRM. While it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use, this type of scheme would be a nightmare for content providers to manage. Any change to the BIOS, the operating system, or the application would change the reported values. How could content providers recognize which reported PCR values were good, given the myriad platforms, operating system versions, and frequenent software patches?
I really don't understand the "trusted boot" functionality is immune to exactly the same argument. You can seal important data under a PCR. But if you upgrade your kernel, you must unseal all such data, upgrade your kernel, seal it all again. If somehow you forget to do this critical step, or if a hacker succeed in modify a single bit of your OS boot image, your data is lost forever. Is this what the function really supposed to do (the data is so important that losing it forever is better than having somebody else getting hold of it), or that I have some seriously misunderstanding of that portion of the paper?
There are so many here that expects Debian installer will address the "very difficult to install for newbies" problem of the old boot floppies. So many that it becomes very compelling to reply every of them about the bad news for them. But then it will waste so much time, that I'd better just write it top-level.
Debian Installer (d-i) is a developer's project. The problem addressed by d-i is the problem of developers, not end-users. You will be very disappointed if you expect a very nice GUI install when trying out d-i. It simply won't make it any more newbie-proof than the old installer of Debian. At least, not now.
The problem addressed by d-i is the difficulty for developers to create boot floppies. It is difficult to create boot disks, no matter what is the distribution. For other distributions where half of the time of the developers is allocated to new installation and where nobody sees any part of the distribution when it is "work in progress", this is no problem. But for Debian, most developers install it once, and never install it again because it is so good in upgrading. For other distributions, installers are the first things they work on when creating a new version. For Debian, it is the last thing that gets started. Not to mention: they must be built manually, e.g., to try making sure that the floppy size is small enough, to remove some files of packages if it doesn't fit, etc. The effect: installation never get well tested.
The d-i project is the study about why creating boot floppies are so difficult, and tries to resolve them so that they can be created automatically. Everyone should really try to read the second half of the "Woody retrospective and Sarge introspective" mail posted by the release manager here . This will give you an idea about what are the issues involved.
So why you should care? First, it will be the installer that you will use. Second, this will be the basis where future improvements to the installers will be made, not the PGI or whatever installer. Third, once it is ready, you will be able to get testing installed directly rather than having to install stable and then upgrade basically all packages to testing (or unstable). For now, test if you can.
Slashdot Mirror
> advising students that they risk lost job opportunities
Strange. When I seek for jobs I worry much more about employers not knowing me enough rather than they know me too much. And no employer will be bored enough to actually read every message in your blog to find your "most silly moment" before he decides whether to hire you.
Because it doesn't fit the needs of the user. As a user, if I show a long page at 75% size, I expect the browser to use the full width to show more words in the page, rather than to show a page that fill use 75% of the screen width. And when I make the words small, I have no intention to make the images small.
> they make 100 billion if they sell you a pill over and over again,
> preferably for the rest of your life or they make 10 billion selling
> the cure. once eradicated from earth, that medicine will be
> completely useless and not able to be sold.
No problem. Just like that you might get 100 billion if every computer is only of 8086 speed and people get to solve their problems, so they have to buy an insane number of computers. If you produce a Pentium 4, people might suddenly be able to solve many problem with a single computer, and they might only be able to earn just 10 billion.
> if you were a CEO with less than impeccable morals (CEO, financial
> backer, etc) would you opt for the 10 billion with a clear
> conscience or 100 billion
The wise CEO see something else: if another company does the research and starts wanna earn the 10 billion drug, and they are stuck with patent laws and can't produce any of those, they earn nothing. If AMD is selling their athlon 64 at the same price at a 8086 when Intel is selling it at exactly the same price, Intel is going to go out of business rather quickly.
I hate patents, but don't attack them with illogical conspiracies.
I do subscribe to LWN. Having to pay is not really a problem. Having to pay for useless content is, no matter whether the payment is done directly by having me keying in my credit card number, or indirectly by having me to view loads of crappy ads.
> "Anyone who's not a building contractor has no
> business hanging a picture. Period."
No. But anyone who's not a building contractor really has no business taking down a wall in your house.
> "Anyone who's not a professional electrician has
> no business plugging anything in. Period."
No. But anyone who's no a professional electrician really (should) have no business removing the front cover of your socket and swap a worn wire in it with a new one.
Anything has an internal and an external interface. I have no problem documenting the external interface: I do write doc comments or PODs. What I won't do is to write comments that essentially says "this internal function is there for doing this and this", because the internal function will be modified faster than I can write comment for it, and if it is so complicated that it really needs comments, it is too complicated anyway. I won't write comments that essentially says "this line of code is there so that this and this happen", because I think that the code should be written in a way that it is trivial to know this for any professional developer, and unless it is impossible to do it, I won't write such a comment. This is what I call a in-code comment.
As of programming, if you are still in an age where senior programmer will make all the design and your junior programmer will code it, it means you will always have bad design. Design comes from the coding, or actually the difficulty of coding. You are spliting up two very closely related tasks to two different people. The same for unit testing.
> I don't know why people (in general) don't like to
> comment code.
I don't write in-code comment because I think writing comments is a horrible way of documentation. I'll prefer writing out-of-code overview documents of the whole set of code so that people (or the future me) will know where to look at for particular behaviour, and what are the general design. After that, it is all the code which serves as the definitive comment---unless there is no way to write code that are sufficiently efficient, clear and easy to maintain at the same time.
As for insufficient skills, those with insufficient skills to read my code has no business with my code. Period.
> I consider them to be nothing more than
> tricks to get around the braindead
> limitations of most mainstream object
> oriented languages
This is a perfectly right comment. For example, if your language supports closure, your need of the command pattern is greatly reduced. If you use a dynamic language like Perl or Python, you will find many patterns like bridges and abstract factories completely useless.
That said, each language has its own set of limitation. Before some genius creates a language that has everything we want (and still has the language comprehensible), we will continue to need some "band aid". If we need band aids, it is probably better to have a standard band aid for each purpose, rather than having a different one each time for no reason.
Any language that supports closures fully can support that. Perl can, Javascript can, and Python can. Perl even have syntactic sugar (in particular, subroutine prototype) which makes it easier to define your own syntax (see how Error.pm does that). None of them are as fast as a compiled Lisp program, and none of them are as flexible (since you don't need to treat the closure as a black box in Lisp, whereas in Perl you can't see what is in the closure argument), though. On the other hand, if you see people who says "Java is a very developer-friendly language that allows you to code very rapidly", they are seriously mistaken.
> Just take a look at the fibonacci test - it
> a stupid useage of recursion, if your
> compiler doesnt optimize out all the
> duplication
I think a good recursion test should be done only to a problem that really needs recursion, not toy problems like Fibonacci that you can do much better in other ways. And in such a test, those with compiler which tries to do funny things like automatic memoization will only get hurt. You can find a large set of such problems by just looking at the acm.uva.es archive.
In such a test, Python *will* be graded poorly. But then, Python is not about speed of programs. It's about speed of reading and writing programs. And when all are off, you can always implement the performance critical part in C or C++.
> Temperature is also more intuitive because
> it is based on humans. 0 is cold, 100 is hot
> so it is the relative feeling of temperature
> rather than the scientific basis of water.
Scientifically, different human being perceives temperature differently, especially when the different individual lives in different part of your country. Do you prefer to have a different temperature unit for each of the states? (e.g., at my place the temperature never falls below 35F. I'd consider 50F already pretty cold. So your reasoning doesn't work for me at all.)
> That 20% difference in functionality and the
> $700 premium that Adobe charges for it is
> what separates GIMPers from Photoshoppers
I'll bet that at least 80% of the people using Photoshop actually use none of the 20% difference in functionality but pay the $700 premium anyway. On the other hand, this is a side issue, nothing to do with freedom. GNU followers, myself included, think that the lack of a fully modifiable and compilable source code of Photoshop makes a significant philosophical *and* practical difference, that we don't think Photoshop is a replacement to Gimp at all. Real GNU followers are okay to pay for software, but not okay if they are asked to conceal it from others.
> You can't convert people to your religion
> by waving an AK-47 in their faces
I don't quite understand what act you are refering to. It seems to me that "waving an AK-47 in others' faces" is an act to threaten others that "if you don't follow our way I'll kill or significantly injure you". I don't see any act here with any similar effect. Perhaps I'm missing something.
If the world starts with no MS from the beginning, there will be somebody who take the field. Software is something that work best when many, many, indeed the majority of people are using exactly the same piece of it. In other words, a monopoly is the normal trend. On the other hand, that company may or may not tried to use nearly as many MS tactics. If not, then free software probably won't be nearly as popular as it is today: really not many people care about a few dozens of bucks or the inavailability of source code, but everybody can see now what world that closed world can lead us to.
On the other hand, what will happen if MS dies tomorrow for whatever reason, with all its assets destroyed? That would be extremely funny. Everybody who had been depending on MS software will suddenly find that their computers are facing a increasing tide of exploits, with nobody who can do anything about fixing them. Probably no sane person will look at any closed source software again. Unluckily (or luckily, depending on who you are), that is not going to happen.
If you don't need security, then simply dropping security support is much easier than installing some software to "pretend" to support it. I see no problem that FreeSWAN refuse to interoperate with anything that can't be made to be secure in the first place.
Both comments are too pessimistic, I believe.
> Getting the Internet to change what's not
> broken is very hard. The fact that our
> default mode of communications is
> plaintext doesn't quite scare most pointy
> haired bosses. They want their stuff
> secured, but there's no sense in switching
> protocols when we can just secure on top
> of the existing protocols with things like
> VPNs, SSH, PGP, SSL, etc.
If you really look at it, those solutions are much more difficult and expensive to setup than freeswan in its finished operation mode, i.e., opportunistic encryption (OE). E.g., in PGP, what you need to do is to install an extension of your mailer, and you publish your public key, and your partner fetch your public key, and get an extension of her mailer, and finally she can read your mail while being happy that the mail is safe. Each party must get and verify the key of everybody quite "manually". On the other hand, OE would just have both parties post a key in the DNS server, install FreeSWAN and done.
> Meanwhile, getting the government to lift
> the crypto-export bans just isn't going to
> happen either. September 11th, 2001 will
> always be brought up anytime anybody wants
> to loosen crypto rules. Being able to talk
> in a way that the US Government can't
> intercept and understand is something that
> truely scares the military and the CIA...
> because if they can't intercept
> communications, they lose one of their
> strongest tools in battle. Maybe the
> crypto-export rules are weak and aren't
> going to stop much, but at least it stops
> everything we can stop using a law, and
> that's better than zero.
Probably no. By now it is completely infeasible for the government to restrict cryptography. Even if they do, no government can stop people from modifying RSA to use a 4096-bit key and use it to encrypt his super-secret, criminal, whatever message. And there is really no feasible way to break it. Cryptography is out there, and there is no way to stop. Better to learn the fact and live with it, rather than to try uselessly fight against it.
It seems to me that the primary reason that the project has to stop is the lack of funding. For OE to be usable, it should be made even easier, but there is no funds to make this possible. It's really sad that such good projects must end this way.
In fact, even in C it is possible to benefit from run-time information. In particular, branch probability can be estimated by compiling the program twice, once to ask the compiler to record how many times each branch is taken, and once to ask the compiler to use the stats obtained to generate code. See the -fbranch-probabilities and -fprofile-arcs options of gcc.
> The fact that it is all being stored in a
..., N-1:
> single block is bad, as reallocating and
> copying that block as it gets larger will
> take linear time, especially if you do
> something stupid like reallocate on every
> addition rather than predict the space
> ahead of time. It is also possible that
> ext is really stupid about adding to the
> data structure, possibly rearranging the
> names into the order of the tree, which
> would cause the slowness you are seeing.
Sorry? We are talking about the directory, not files. How to pre-allocate? In any case a single block (1024 bytes, typically) does not have enough room to store the directory that I'm creating, which contains thousands of files! And what "data structure" you are talking about?! Do you have *any* knowledge about the ext2/ext3 filesystem?
> *Looking up files* in the directory takes
> time that is approximately the log of the
> number of files, indicating a tree.
Are you really sure? Did you ever tested your "theory"?
Lookup a non-existing file using ls in a freshly-mounted ext3 directory with N empty files created in advance, named 0, 1, 2,
0 files: 0.004s
10000 files: 0.006s
20000 files: 0.010s
30000 files: 0.013s
40000 files: 0.017s
50000 files: 0.021s
60000 files: 0.024s
(Creating 60000 files takes more than 5 minutes, so I have to stop.) Doesn't look like logarithmic growth, right?
> The filenames have to be stored somewhere,
... (I got bored waiting)
> you know.
In the directory, as a long, plain list. No B-tree, no hash table. Nothing to improve the efficiency, apart from the dentry-cache in the memory. But then, to access a directory still require the kernel to load the whole directory.
If you don't believe me, try an experiment: create a directory, try to create 100,000 empty files in it, and every 1000 files created you will print the current time. If the directory is implemented by a b-tree, the time taken should be about constant (actually, should be increased in the order of logarithm of the number of files within the directory). If, on the other hand, it is implemented by a list, you the time taken should be increased very steadily. My experiment shows the following:
00Thu Dec 11 14:30:35 HKT 2003
01Thu Dec 11 14:30:38 HKT 2003
02Thu Dec 11 14:30:41 HKT 2003
03Thu Dec 11 14:30:45 HKT 2003
04Thu Dec 11 14:30:50 HKT 2003
05Thu Dec 11 14:30:55 HKT 2003
06Thu Dec 11 14:31:00 HKT 2003
07Thu Dec 11 14:31:06 HKT 2003
08Thu Dec 11 14:31:13 HKT 2003
09Thu Dec 11 14:31:20 HKT 2003
10Thu Dec 11 14:31:29 HKT 2003
11Thu Dec 11 14:31:38 HKT 2003
12Thu Dec 11 14:31:48 HKT 2003
13Thu Dec 11 14:31:58 HKT 2003
14Thu Dec 11 14:32:10 HKT 2003
15Thu Dec 11 14:32:21 HKT 2003
16Thu Dec 11 14:32:34 HKT 2003
17Thu Dec 11 14:32:47 HKT 2003
18Thu Dec 11 14:33:01 HKT 2003
19Thu Dec 11 14:33:16 HKT 2003
20Thu Dec 11 14:33:33 HKT 2003
21Thu Dec 11 14:33:49 HKT 2003
22Thu Dec 11 14:34:04 HKT 2003
23Thu Dec 11 14:34:21 HKT 2003
24Thu Dec 11 14:34:40 HKT 2003
25Thu Dec 11 14:34:58 HKT 2003
26Thu Dec 11 14:35:17 HKT 2003
27Thu Dec 11 14:35:40 HKT 2003
28Thu Dec 11 14:36:03 HKT 2003
29Thu Dec 11 14:36:24 HKT 2003
30Thu Dec 11 14:36:47 HKT 2003
It shoulds the amount of time needed to create 1000 files grows steadily from 3 seconds to 23 seconds and has no sign to stop growing. Anybody with slight data structure knowledge should understand that there is not a B-tree or any efficient data structure underlying the ext3 directory.
You obviously don't have actually see a hex-dump of your ext3 filesystem. The directories *are* a sequential long list. There is a patch to use a hash, but the patch is not in the default stable kernel, yet.
Swap space is always extremely simple, much simpler than the FAT filesystem. It is not used to hold directories and files, so it has very little structure. All you need is (1) a signiture that tells it is a swap space; (2) a few parameters like what is the size of each block within the swap space, which is supposed to be the same as the page size, and the size of the whole swap space; (3) a list of "bad blocks" that must be kept unused, and (4) the actual data. You can read the man page of mkswap(8) in Linux to know the details.
> c++ isn't portable, normally. C++-- might be
> though. Then again, it might not be. The
> java language is very standardized; and in
> case you shouldn't have a compiler on that
> platform, the bytecode is too!
If you see non-conforming C++ implementation, you should go blame the compiler vendor, not the language. And Java is not standardized at all. C++ goes through the standardization process and now have ISO standards, Java has nothing about it. C# does have a ECMA standard as well, so Java is alone on the lack of standardization. Basically, Sun decide on it, and everybody has to follow. Now you can see why there are so many mis-features or lack-of-features in that language: it has never been beaten to death by vendors before it is set in stone.
> [OEMs] put it on computers because Windows
> is the REASON that people buy the computers.
Most people buy computers because they want to do tasks like preparing and printing documents, browsing and using the web, sending, receiving, reading and posting E-mails and newsgroups, managing their bank accounts and their tax forms, creating presentations, getting, storing photos and movies they get from their digital cameras, etc. Windows is nearly never the "REASON" why people buy their computers. Instead people scold Windows when the work they want to get done gets in the way when Windows tell them that their applications has an error.
This is, of course, unless you equate preparing and printing documents with Microsoft Word, browsing and using the web with Internet Explorer, sending, receiving, reading and posting E-mails and newsgroups with Outlook Express, managing their bank accounts and their tax forms with Microsoft Money, creating presentations with Microsoft PowerPoint, getting, storing photos and movies they get from their digital cameras with Adobe Photoshop, etc. But then its the problem of the clueless user, not the problem of Linux.
This means that even if an application marks a certain memory area non-executable (by not providing the PROT_EXEC flag upon mapping it) under x86, that area is still executable, if the area is PROT_READ.
No. The x86 page table has 12 bits per page table entry for storing page information. It contains a bit for R/W (read/write) which you can force a page read-only; and it contains a bit U/S (user/supervisor) which you can force a page usable only by the kernel. There is nothing which says "this page must not be executed as code". So Linux kernel actually has an interface that only some hardware provides. I don't think now it still has spare bit to give for executable bit.
Furthermore, the x86 ELF ABI marks the process stack executable, which requires that the stack is marked executable even on CPUs that support an executable bit in the pagetables.
It is not about "do the right thing". The processor simply has no such bit, so there is no new "right thing" for it to do---it is already doing the right thing. The processor assumes that segmentation is used to enforce execute permission, so that each library code should be allocated a segment and inter-segment jumps and calls should be used to access them. In such way only read-only code segments are executable. Linux simply decided at the very beginning not to employ this facility.
ELF is not designed by Linus. And even if ELF is changed so that stack is not assumed executable by default (which probably break some programs that rely on executable stack), all computers from 386 to P4 will not benefit from it.Where is the "Burn all your JPEG" campaign running? Or "Burn all your JPEG-making digital camera" campaign?
The page is really helpful in understanding what TCPA is. However, there is one point that I don't quite understand. The Why TCPA document says:
Fine, I can have data for my Linux partition that is unreadable even if my naughty sister boot a Windows XP on it. Seems something that I might want. Then later in the article, it says:
I really don't understand the "trusted boot" functionality is immune to exactly the same argument. You can seal important data under a PCR. But if you upgrade your kernel, you must unseal all such data, upgrade your kernel, seal it all again. If somehow you forget to do this critical step, or if a hacker succeed in modify a single bit of your OS boot image, your data is lost forever. Is this what the function really supposed to do (the data is so important that losing it forever is better than having somebody else getting hold of it), or that I have some seriously misunderstanding of that portion of the paper?
There are so many here that expects Debian installer will address the "very difficult to install for newbies" problem of the old boot floppies. So many that it becomes very compelling to reply every of them about the bad news for them. But then it will waste so much time, that I'd better just write it top-level.
Debian Installer (d-i) is a developer's project. The problem addressed by d-i is the problem of developers, not end-users. You will be very disappointed if you expect a very nice GUI install when trying out d-i. It simply won't make it any more newbie-proof than the old installer of Debian. At least, not now.
The problem addressed by d-i is the difficulty for developers to create boot floppies. It is difficult to create boot disks, no matter what is the distribution. For other distributions where half of the time of the developers is allocated to new installation and where nobody sees any part of the distribution when it is "work in progress", this is no problem. But for Debian, most developers install it once, and never install it again because it is so good in upgrading. For other distributions, installers are the first things they work on when creating a new version. For Debian, it is the last thing that gets started. Not to mention: they must be built manually, e.g., to try making sure that the floppy size is small enough, to remove some files of packages if it doesn't fit, etc. The effect: installation never get well tested.
The d-i project is the study about why creating boot floppies are so difficult, and tries to resolve them so that they can be created automatically. Everyone should really try to read the second half of the "Woody retrospective and Sarge introspective" mail posted by the release manager here . This will give you an idea about what are the issues involved.
So why you should care? First, it will be the installer that you will use. Second, this will be the basis where future improvements to the installers will be made, not the PGI or whatever installer. Third, once it is ready, you will be able to get testing installed directly rather than having to install stable and then upgrade basically all packages to testing (or unstable). For now, test if you can.