Because most of it is unenforceable, and certainly doesn't cover the entirety of the problem. Let's check it point by point.
I disagree. I work for a rather large company in which the average employee is probably dealing with less sensitive data than the average White House employee. Yet we have a policy that requires all laptop hard disks to be encrypted (regardless of what is stored on them), all remote logins to use two-factor authentication, etc. These are basic security rules that every company (large or small) should apply.
1. Encrypt all data on mobile computers/devices which carry agency data unless the data
is determined to be non-sensitive, in writing, by your Deputy Secretary or an
individual he/she may designate in writing;
So basically ALL data will be sensitive. We're not longer talking about CIA operatives or Pentagon generals with state secrets under the arm. It's the secretary of the editor of the "Golden Days" monthly that will access the name of one of the retirees it serves from her son-in-law's computer to see why Ms. Applewhite didn't receive her beloved issue last month. The secretary is not only not going to encrypt the data, she's blissfully unaware that her son-in-law hard disk is completely shared on eMule due to her son-in-law's imperfect grasp of eMule's share facility.
I think that adding an exception for non-sensitive data is stupid. All data on mobile computers/devices should be encrypted, period. If you have a laptop that could be used to store potentially confidential data (even if it does not contain confidential data right now), then there is no good reason to leave the hard disk unencrypted. Yes, this includes the secretary's laptop, USB disks, etc. And if that secretary takes the laptop that she uses at the White House and allows her son to access it (despite the user account password and disk encryption password), then she should be fired. The laptop does not belong to the secretary; it belongs to her employer and it is very likely that she had to sign a clause stating that she will not allow unauthorized persons to use her account and other credentials. Also, the laptop should not allow connections to an untrusted network.
2. Allow remote access only with two-factor authentication where one of the factors is
provided by a device separate from the computer gaining access;
Yeah, sure. I guess somebody is underestimating the ubiquity of data communications nowadays. Or thinking still about CIA operatives mainly.
What's wrong with that? The "ubiquity of data communications" is only true if you have a rather open environment. But if the internal network of your department or company is isolated from other networks or uses a firewalled network that severely limits both the inbound and outbound traffic, then the requirement to use two-factor authentication makes sense.
If all employees only have a limited access to the web and e-mail through filtering proxies and servers, then it is possible to check for suspicious activities such as people trying to establish reverse HTTP tunnels and other tricks. It is still possible for some covert channels to be established by insiders, but at least the risks are much lower than with a wide open network. Once you have a reasonably secure network, you should be careful about any access from the outside. If you only rely on a password or on a token that can be stolen, there is a risk that an external attacker can access the network and transfer a lot of data before the problem is detected. This is where the two-factor authentication is useful: it lowers the risks of external attacks.
In summary, these requirements make sense and are already common practice in the industry. I am wondering why such a basic policy has not been enforced much earlier.
The purpose of copyright is to create and enforce a monopoly via the government.
That statement is incomplete. It should be to create and enforce a temporary monopoly via the government.
I have absolutely no problems with a copyright system that is reasonably limited in time and in scope. I agree that it should be illegal to copy software, movies, songs, books or other works that have just been published and for which the author (and to some extent, the publishers and distributors) deserves some compensation. However, this protection should be limited:
in time: a copyright that lasts a few years is fine. This could range from 10 to 30 years from the date of publication, for example. But a protection that lasts for 90+ years after the date of publication of lasts for 50+ years after the death of the author is unreasonable. It is hard to argue that such copyright extensions are really benefiting the community.
in scope: protecting fair use is as important as protecting copyright. I should be allowed to cite reasonably short excerpts from a work without asking for permission. I should also be allowed to make private copies of a work or to store it on a different medium (note that this does not include sharing these copies with friends or reselling them).
Unfortunately, the current system is not reasonably limited in time and in scope.
Here is another test of <ul> and <ol>, in case anyone looks at this...
This is a <li> inside <ul>.
This is another one.
We should see bullets or some other decoration in front of each item.
There should be no gray lines or arrow in front of the first item.
This is a <li> inside <ol>.
This is another one.
It should be intented exactly as the previous list.
There should be no negative indent (compared to other paragraphs).
And there should be a normal margin (one blank line) between this item and the next paragraph.
As I explained in the bug report, it should not be too hard to fix this problem by resetting the definition of the list elements when they are used inside div.commentBody.
Just for fun, here is a <li> inside <ol> inside <blockquote>
The current Java license is obviously unacceptable;
Is it? The main problem seems to be the indemnification clause. But Java is not the only package in the standard archive or in non-free that has such a clause. And it appears that nobody complained about these other packages.
Here is a quote from another message from the Anthony Towns (DPL) in that thread:
From the xorg-x11 copyright file:
] 11. Indemnity. Recipient shall be solely responsible for damages arising, ] directly or indirectly, out of its utilization of rights under this License. ] Recipient will defend, indemnify and hold harmless Silicon Graphics, Inc. ] from and against any loss, liability, damages, costs or expenses (including ] the payment of reasonable attorneys fees) arising out of Recipient's use, ] modification, reproduction and distribution of the Subject Software or out of ] any representation or warranty made by Recipient.
From the openoffice.org copyright file:
] Therefore, if ] a Contributor includes the Program in a commercial product offering, such ] Contributor ("Commercial Contributor") hereby agrees to defend and indemnify ] every other Contributor ("Indemnified Contributor") against any losses, damages ] and costs (collectively "Losses") arising from claims, lawsuits and other legal ] actions brought by a third party against the Indemnified Contributor to the ] extent caused by the acts or omissions of such Commercial Contributor in ] connection with its distribution of the Program in a commercial product ] offering.
And people who want a fully supported 64-bit operating system out of the box go with Debian Stable, but of course there's the "it's severely outdated" argument.
Another argument is that the previous post talked about AMD64. The only official 64-bit Debian Stable ("sarge") is for Itanium, not for AMD64. Of course there is the unofficial AMD64 port that is now part of Debian Testing ("etch") and Unstable ("sid"), but the "sarge" version will always remain unofficial.
Good for 64-bit servers, tends to require many backports (or risk using Debian Sid) if you want more cutting-edge desktop packages.
Using Debian testing ("etch") is usually safer than using "sid". For AMD64 systems, I would recommend using it instead of the slightly outdated and less stable unofficial "sarge" version. In fact, I currently recommend using a base install from "etch" and pulling Xorg 7 and its dependencies from "sid" because the X server in "sid" (unstable) turns out to be more stable than the one in "etch". Or just use Ubuntu "Dapper Drake".
We use Urchin - now "Google Analytics". Unless you want to delete cookies every page hit, and use the Web Developer Firefox plugin to remove hidden fields for every form submission, we pretty much have you tracked.
Funny that you mention this... I use Firefox with the Adblock extension, and here are some rules found in my preferences:
*.google-analytics.com *urchin.js
This works quite well for me. I added these rules several months ago, when urchin started appearing on some web pages and making them load slower. These rules block the "urchin.js" from Google but also from other sites using their local copy of that script. The pages load faster and this makes me feel better.
The only minor issue is when I activate the FireBug extension and view Slashdot, it reports a Javascript error saying that "urchinTracker" is not defined. But this is to be expected, since the corresponding script is not loaded.
I don't think that Novell is to blame for that. On the contrary, I think that Novell has put SuSE back on the right track.
I have been using SuSE since version 4. Yes, this is a long time ago. I have tried every single version since then. This makes a nice pile of boxes.
SuSE was by far my favorite distro until about version 8.1. Then it started getting bad (broken package dependencies, too much reliance on the graphical version of YaST2 while keyboard support was half-broken in the command-line version, settings and directory hierarchies incompatible with other distros, etc.). From my point of view, versions 8.x, 9.x and 10.0 sucked compared to other distributions available at that time. Now they are becoming good again with version 10.1.
I had really lost my faith in SuSE after several bad experiences with versions 8.x and 9.x. Version 10.0 was getting better but still a bit rough around the edges. Version 10.1 is much better. I hope that version 11 will be even better and will be able to compete with other distributions such as Ubuntu in terms of polish, features and user experience. (and before you ask: no, Ubuntu is not my favorite distro although I recommend it to most people)
Nvidia already needs documentation in order to write drivers. Releasing documentation that they already have would cost them VERY VERY little.
I bet that releasing that documentation would cost them a lot - almost as much as releasing the source code. There is no reason to think that the company internal documentation would be cleaner than the source code. They would have to get that documentation cleared by an army of lawyers and check if it contains any of their own intellectual property or any trade secrets from third parties. Then it would probably cost them to support this documentation, etc.
Futhermore, nvidia could choose to release docs for their cards which are no longer "state of the art" which would allow the community to take over maintainance and not give away "secrets" to their competitors (once the cards are out for 6 months or so, there are no "secrets" anymore that would harm their ability to compete.)
You are considering this from the wrong point of view. Think about it from the point of view of a company that wants to make profits. Doing what you suggest would encourage their Linux customers to keep on using obsolete cards, or maybe buy them second-hand from Windows users who have moved to more recent cards in the meantime. This would discourage these potential customers from buying their latest products and hope that a (closed source) driver is available or will be available soon.
This would be a very bad message for a company: their discontinued products (on which they cannot make profit anymore) would be competing more strongly against their current products. So it is not in their interest to release specs for anything that could still compete with their current products. They could probably do it for products that are really irrelevant now (say, 5 years old) but certainly not for products that are only 6 months old.
Note that I am playing the devil's advocate here, taking the point of view of a company interested in profit and not caring too much about being perceived as a good citizen in the tiny (but growing) open source and free software community. Alas, this is still the point of view of many companies.
using the noise from your soundcard disconnected mic? It is just as random and does not require a radiotelescope the size of a small house...
There are two problems:
It is not just as random. The electrical noise amplified by your soundcard may be influenced by what you are doing on your computer, for example.
It does not allow two parties located far away from each other to get the same signal at the same time (or almost the same time). The nice thing about quasars is that anyone on Earth or in space can record their signal. Your soundcard is tied to your machine and cannot be used by anyone else.
Having a source of noise such as a disconnected sound card or a CCD sensor in a black box can be useful in cryptography if you want to generate truly random bits. But this is not the only thing that this article is about: the signal from the quasars can be received by both parties, which provides a good one-time pad.
The length of the "one time pad" is large, but the number of them available? I mean the number of quasars that are good enough receivable to use for this purpose. I have no idea, but I doubt if its more than 2^32. In that case, brute force would be quite easy: just try each of the available quasar signals.:
Record the signal of each of them at time T, also record the encrypted message at time T, and try them all out in a fast computer.[...]
Well, you have a big problem with your time T. How do you know it? If you do not know the source (which quasar is used), it is also unlikely that you know the exact time T used for the start of the random stream. It is unlikely that you know it with a better precision than a few seconds. If the two parties do not exchange messages frequently or do not re-negociate the start of the random stream frequently, then you may not even know T with a precision of a day.
The NewScientistTech article does not give details about the amount of data available from the quasars, but other articles mention that quasars are typically observed in relatively high frequencies (20-40 GHz). Even if the signal strength is sampled with a low resolution and only a few truly random bits are extracted from the stream, you would still have a stream of bits that is in the Gbps range. This is a reasonably large amount of random data.
So even if the number of usable quasars is rather low (say, a few thousands: 2^10 instead of 2^32 as you mentioned), you would need a lot of antennas and petabytes of storage to record all these random streams. You would have to store something in the order of 2^40 bits per second for several seconds or even days (the uncertainty on T). This is not impossible if you have a large budget, but this is difficult and expensive.
It could even be much worse than 2^40: a recent catalogue of quasars from March 2006 mentions 85221 of them, with new findings doubling this number every second year: 48921 in 2003, 23760 in 2001, etc. Let's say that 2^15 of them are usable (and that you have 2^15 antennas at your disposal). If the signal strength is sampled with a medium resolution of 8 bits at a frequency of 30GHz and your uncertainty interval on T is about one hour, you would need to store 2^15 * 2^3 * 2^35 * 2^12 = 2^65 bits of data before starting your brute force attack. Good luck!
Once you have all this data, you still have to do the brute force attack. You wrote "just try each of the available quasar signals." This is correct but you ignore the fact that the random stream is unlikely to be used as is. It will probably be used to seed a stream cypher. In the simplest case, the random stream would be hashed a couple of times before being xor'ed with the data. You will need a huge amount of computing power to perform all these operations and try each of the available signals at each possible time offset.
Note: it is unlikely that both parties can get the signal and be synchronized with a nanosecond or picosecond resolution. So they would probably negociate a time window (say, with a resolution of one second or so) and some kind of unique marker within that time window in order to know exactly when to start. If you are the attacker and you cannot know which source is used, you probably do not know the time window nor the marker. But even in the unlikely case that you would have a way to obtain one or both of these, you would still have the problem of storing the huge amount of data from all quasars until you know which part of it should be analyzed.
So although a brute force attack based on recording all qasars is not impossible, it is not really easy. And anyway, my first reaction when I started reading this story was exactly like the comment mad
You just can't get any better performance or security by doing it all yourself.
The performance can be debated, but you have got the security argument backwards. If you use pre-packaged binaries, you can get security updates quickly and automatically because any responsible Linux distributor will provide updated packages in a timely manner. This is especially useful if you maintain a large number of machines and want to make sure that the latest security patches are quickly applied to all of them.
On the other hand, compiling your own software requires you to pay attention to all security announcements and apply the security patches yourself. It may be possible to automate that to some extent (e.g., Gentoo provides some help for security patches), but not as easily as with the pre-packaged binaries.
From a security point of view, I am glad that some others are doing most of the work for me. The issue of performance can be debated because there are many pros and cons, but security is usually better for the pre-packaged binaries. Note that I am talking about security from the point of view of applying the latest security patches and staying ahead of the script kiddies, not in terms of initial configuration of the system. And by the way, I am not against compiling software on my own because I compile several packages from sources (directly from cvs or svn, especially for the stuff that I contribute to). But then I am aware that the security may actually be weaker for those packages than for the ones that I can update automatically.
Their principles state that there can't be "extra" versions that cost money in addition to the free version, too.
This does not prevent another company (Linspire) from offering optional services on top of Ubuntu. Just like any company can offer free or non-free software that can be installed on top of Ubuntu or on top of any other Linux distribution or even any other operating system.
TWiki also includes some plug-ins that may be useful for the author of this article, such as the SyntaxHighlightingPlugin (which uses enscript as a back-end).
I am not sure that I would use a wiki for viewing source code because there are better tools for that (from viewcvs to gforge). But if you really want to, then TWiki is probably the one that has the most useful features for a corporate environment.
Needless abstraction is one of the many geek culture relics that can and should be changed in the name of efficiency. The real problem is that too many people are engaged in it. If this was recognized as a poor programming practice, it could slowly be reversed. There's something right with considering non-end-users. Standardization both speeds adoption and creates stable intuitive metaphors. This makes the shell more useable. Each shell environment is getting more complex, partly due to this old hackish mentality.
I would not consider this to be needless abstraction, but rather some combination of historical and practical reasons. You take the rather unlikely example of a program that would regress from a descriptive name to a project name. The project names are usually not descriptive for practical reasons: as others have pointed out, uncommon names or acronyms are more likely to be unique and less likely to conflict with other projects in the same area.
There is a plethora of programs able to edit text files (source code, etc.). If each of these projects and the corresponding binaries were called "text_editor", it would be rather hard to run the one that you want to use from the command line. It is fine to have just one or several of them listed as "Text Editor" in the desktop menus, but it is better to have a short and unique name to use from the command line. Note that there are good reasons to have more than one text editor available from the command line, even if only one of them appears in the menus (e.g., picking the best tool for a specific task, personal preferences, etc.)
Once a project starts with a unique name, it stays around because this is what the existing user base of that program expects to find. There is some inertia that prevents the project from being renamed and use a more descriptive name. So you may end up with binaries that have non-descripive names. On the other hand, most users never need to know the name of the binaries: they show up with a descriptive name in the desktop menus. Same for the installation of these programs: most package managers let the user view the packages by category. So if you want to install some application for editing images, then you go to the "Applications / Image Editing" section and then you find GIMP, Inkscape and others.
In 20 years when I have to work on a machine running an OS I have no contemporary reference for, do you really expect that these pet project names (which is what they are) are going to be so easy for me to remember or associate? Adding an additional layer of abstraction is geeky-fun, not practical.
As explained above, most users do not have to care about the project names: you can simply use the descriptive names provided in the various menus. If you want to use the command line and invoke the programs directly, then it is useful to know these names but this may not even be necessary: it would be possible to provide shell aliases, wrapper scripts or symbolic links so that typing "text_editor" would start one of them or maybe tell you about the available options. So even from the command line, it would be possible to work without knowing the project names.
By the way, I agree with you that it would be nice if all projects could use intuitive names. Also, I do not like the project names that are deliberately obscure. But using intuitive names is difficult to achieve when there are several projects addressing similar needs and nobody knows in advance which one will "succeed" and will be adopted as the standard in its area (if that ever happens).
[...] if you're making a user-oriented app like a windows environment in OSS, why would you choose to regress to naming binaries after development names?
There is nothing wrong with that. Giving binaries a short name (project name or codename) means that they are easier to type. Advanced users who invoke GUI programs from the command line instead of using the menus are likely to know the project name anyway. If I use the command line, it is easier to type "gimp" than "Image Editor" or "GNU Image Manipulation Program" (note that auto-completion would not help much if you also have "Image Viewer", "Image Search", etc.).
The command line is supposed to be efficient, not descriptive. It would be impractical for the frequently used commands such as "cd", "ls", "cp" and others to have descriptive names. So it makes sense to use short names for the command line (even if they may be a bit obscure for those who do not know their origin) and use longer, more descriptive names for the desktop menus.
By the way, OSS is not the only environment that uses different names for the command line and for the menus. For example, look at the names of control panel components in Windows: descriptive names in the menus, cryptic names for the command line.
For your information, here is a direct link to the chapter of the GNOME HIG dealing with menu item names. It contains good examples of descriptive names. This was published two years ago, so any application that still uses cryptic names in the menus is violating these guidelines and should be fixed.
Actually, it's not. It's a phrase, "rendez vous", or "present yourselves".
I think that you are confusing two things:
The word "rendez-vous" (composite noun) means "meeting" as correctly stated by the grandparent. This is sometimes associated with dating.
The phrase "rendez vous" (two words: verb and pronoun) means "surrender" if these two words are used alone, usually punctuated by an exclamation mark. If these words are followed by a location such as "Rendez vous à cette addresse." (or the more polite form "Veuillez vous rendre à cette addresse.") then it means "present yourselves."
Of course, writing RendezVous as OneWordWithMixedCapitalization does not help. The correct spelling would be Rendez-Vous.
Working under the assumption that submitters to slashdot are readers, and that, as you say submissions are slow during the night shift; it stands to reason that readership is also slow during the night shift.
As such, it is rather a waste to post stories in the middle of the night when no one is going to read them until next morning.
In defense of jamie, ScuttleMonkey and other editors, I would say: editor's night shift != reader's night shift.
Although most of the Slashdot readers may live in the US, there is a significant percentage in Europe, Asia, Australia and other parts of the world. For them, the editor's night shift is precisely the time at which they read Slashdot.
I'm not going to claim that the spammers are being deliberately picked or given preference due to some unknown deal. I am going to claim that, consciously or not, certain submitters are being accepted more readily than others irrespective of the relative merits of the submissions, and I don't think this claim lacks ample support. At the very least, the fact that a story that links to a blog is frequently picked over a similarly well-worded submission with links to primary sources shows that the system is not working even for those most popular stories.
This could be explained partly by this other comment from CmdrTaco: the first submission on a given topic is more likely to be posted than the other ones, even if the other stories are written in a better way. The queue spammers submit so many stories that they are more likely to be the first ones on any given topic than many other submitters who do not have "posting stories to/." as their main hobby. Unfortunately, it does not seem to matter if the other stories are well-written or not because they were not first.
Solving this problem may require more work from the editors, because they would have to pay attention to more submissions (on a given topic) rather than stopping at the first one that look "good enough". It would also require all editors to adhere to the policy of rewarding quality over speed.
The fact that it is more of a problem now than in the early years of/. (or Chips'n Bits) is probably a side effect of the popularity of this site: getting a link published on the front page is seen as valuable by some people, so they start competing to have their story published.
I thought you might all like to know that cold fusion is now a practical reality, according to _this_ Nature article. _This_ is the original paper on the subject. And, _here_ is some commentary by a relevant scientist on the matter. (This came to my attention when slashdot user _somebody_ submitted a link to his personal _blog_)
Hmmm... Nitpicking, but I would prefer this version instead (note what is linked):
I thought you might all like to know that cold fusion is now a practical reality, according to _this Nature article_. Compare with _the original paper_ on the subject. And, here is _some commentary_ by a relevant scientist on the matter. (This came to my attention when slashdot user _somebody_ submitted a link to his _personal blog_)
I prefer to reward speed over quality. But that is a flexible rule too.
I do not understand how this argument applies to the story selection. As an editor, you are the one who decides when you look at the stories and when you publish them. By the time you look at 5 stories that are on the same subject matter, these stories are already there (in the queue) so the time at which they were originally submitted is mostly irrelevant and will not have any influence on the time at which the story is posted.
There is currently no feedback to the submitter saying "your story has been accepted because you were the first one to submit it" or "your story has been accepted because it was well-written" or "because it had more relevant links". Similarly, there is no feedback to the ones who get rejected saying "your story has been rejected because another submission on the same topic was received earlier" or "your story has been rejected because of its lousy quality". In most cases, those who submit stories have no way to know if they were first or not. Therefore, I would argue that there is no clear incentive for submitting stories as fast as possible.
On the other hand, if we look at the feedback posted in the comments, I have seen more complaints about the quality of the stories than about the fact that other sites got the news first. This seems to indicate that it would be better to reward quality rather than speed in order to minimize the complaints and other off-topic discussions on some stories.
If I may suggest something, it would be that you try to look at all 5 stories on the same subject matter and pick the one that has the best summary or the best links rather than the one that was submitted first.
One very interesting point was the vast difference in the amount of available space after a partition and format between the different filesystems.
Unfortunately, that graph is rather misleading. The ext2 and ext3 filesystems keep some percentage of the disk space as "reserved" and only root can write to this reserved area. This is useful if the disk contains/var or other directories containing log files, mail queues and other stuff. Even if a normal user has filled the disk to 100%, it is still possible for some processes owned by root to store some files until an administrator can fix the problem. On the other hand, if your filesystem contains only/home or other directories in which users are not competing for disk space with processes owned by root, then it does not make much sense to have a lot of disk space reserved for root. That is why you should think about how the filesystem is going to be used when you create it, and set the amount of reserved space accordingly.
The default behavior for both ext2 and ext3 is to reserve 5% of the disk space for root. You can see it in the section Creating the Filesystems from the article:
4883860 blocks (5.00%) reserved for the super user
You can change this behavior with the -m option, specifying the percentage of the disk space that is reserved. The article did not mention how the filesystem was supposed to be used if it had been used in production. However, I would guess that the option -m 0 or maybe -m 1 could have been used in this case. This would have provided a fair comparison and suddenly you would have seen all filesystems in the same range (close to 373GB available), except maybe for Reiser3.
#2 are pointless, they won't accept anything that isn't their original system, they're the one that will never switch to MacOSX or Linux because it's not Windows+Office
I disagree. Group #2 is probably the most important group. Keep in mind that being tainted does not only mean being exposed to Windows+Office, but also to any other desktop environment, including Linux, OS X or others.
This includes for instance the Linux FVWM users who will be frustrated that the default GNOME window manager does not offer an option to bind the mouse buttons in the "right way", or the OS X users who will be frustrated that KDE tries to copy Windows in some places and uses the "wrong" button order. Every person who reads this on Slashdot is already in group #2. The tainted users will be biased towards one environment or another, often without realizing it. So they will think that some applications will be more usable than others because of their past experience, which will strongly influence what they think is the "right" way to do things.
But being tainted does not mean being a zealot. There are many Windows users who enjoy using KDE or GNOME when they are confronted with these new environments for the first time. Even if they cannot instantly forget all their past experience with computers, they are still a very useful test group for usabilty.
The problem isn't the memory or the processor; it's X Windows and a distro not optimised for a resource-limited mobile device.
I assume that you haven't tried the N770 yet. The applications are reasonably optimized for that device and from my point of view, the benefits of using X11 outweight the drawbacks. Opening a new application takes time (a few seconds) but once the application is loaded, it runs quite well. Most of the performance bottlenecks that I have hit seem to be related to the size and speed of the memory (and CPU) rather than X11.
I have developed and ported software for a large number of small devices using Windows CE, Symbian (UIQ) and now Maemo (Linux/X11/GTK+). Although Symbian is a nice OS from a conceptual point of view and is designed to perform well on resource-limited devices such as mobile phones, writing software for it is very painful. Writing for Windows CE seems to be much easier at first, but there are many gotchas: you think that you can use most of the Windows API, but then you discover that the function that you need is not supported or has some limitations forcing you to rewrite a lot of code from scratch. Writing for Maemo is a refreshing experience: of course there are some limitations, but once you have set up the Scratchbox environment, development and testing is relatively easy (compared to other mobile devices). So from a developer's point of view, the choice of the X Window System and an open distribution such as Debian is a good one.
I wouldn't mind having more memory or a more powerful CPU in this device. But as it stands now, the 770 is already a very nice gadget for web browsing, checking the news or previewing/uploading pictures taken from my mobile phone (SonyEricsson K750).
Slashdot Mirror
I disagree. I work for a rather large company in which the average employee is probably dealing with less sensitive data than the average White House employee. Yet we have a policy that requires all laptop hard disks to be encrypted (regardless of what is stored on them), all remote logins to use two-factor authentication, etc. These are basic security rules that every company (large or small) should apply.
I think that adding an exception for non-sensitive data is stupid. All data on mobile computers/devices should be encrypted, period. If you have a laptop that could be used to store potentially confidential data (even if it does not contain confidential data right now), then there is no good reason to leave the hard disk unencrypted. Yes, this includes the secretary's laptop, USB disks, etc. And if that secretary takes the laptop that she uses at the White House and allows her son to access it (despite the user account password and disk encryption password), then she should be fired. The laptop does not belong to the secretary; it belongs to her employer and it is very likely that she had to sign a clause stating that she will not allow unauthorized persons to use her account and other credentials. Also, the laptop should not allow connections to an untrusted network.
What's wrong with that? The "ubiquity of data communications" is only true if you have a rather open environment. But if the internal network of your department or company is isolated from other networks or uses a firewalled network that severely limits both the inbound and outbound traffic, then the requirement to use two-factor authentication makes sense.
If all employees only have a limited access to the web and e-mail through filtering proxies and servers, then it is possible to check for suspicious activities such as people trying to establish reverse HTTP tunnels and other tricks. It is still possible for some covert channels to be established by insiders, but at least the risks are much lower than with a wide open network. Once you have a reasonably secure network, you should be careful about any access from the outside. If you only rely on a password or on a token that can be stolen, there is a risk that an external attacker can access the network and transfer a lot of data before the problem is detected. This is where the two-factor authentication is useful: it lowers the risks of external attacks.
In summary, these requirements make sense and are already common practice in the industry. I am wondering why such a basic policy has not been enforced much earlier.
That statement is incomplete. It should be to create and enforce a temporary monopoly via the government.
I have absolutely no problems with a copyright system that is reasonably limited in time and in scope. I agree that it should be illegal to copy software, movies, songs, books or other works that have just been published and for which the author (and to some extent, the publishers and distributors) deserves some compensation. However, this protection should be limited:
Unfortunately, the current system is not reasonably limited in time and in scope.
You should submit them to the Sourceforge bug tracker for the slashcode project.
But I have just done it for you: http://sourceforge.net/tracker/index.php?func=deta il&aid=1502349&group_id=4421&atid=104421
Here is another test of <ul> and <ol>, in case anyone looks at this...
As I explained in the bug report, it should not be too hard to fix this problem by resetting the definition of the list elements when they are used inside div.commentBody.
Both <blockquote>...</blockquote> (for normal quotes) and <ecode>...</ecode> (for pre-formatted code) will do that for you
Is it? The main problem seems to be the indemnification clause. But Java is not the only package in the standard archive or in non-free that has such a clause. And it appears that nobody complained about these other packages.
Here is a quote from another message from the Anthony Towns (DPL) in that thread:
Another argument is that the previous post talked about AMD64. The only official 64-bit Debian Stable ("sarge") is for Itanium, not for AMD64. Of course there is the unofficial AMD64 port that is now part of Debian Testing ("etch") and Unstable ("sid"), but the "sarge" version will always remain unofficial.
Using Debian testing ("etch") is usually safer than using "sid". For AMD64 systems, I would recommend using it instead of the slightly outdated and less stable unofficial "sarge" version. In fact, I currently recommend using a base install from "etch" and pulling Xorg 7 and its dependencies from "sid" because the X server in "sid" (unstable) turns out to be more stable than the one in "etch". Or just use Ubuntu "Dapper Drake".
Funny that you mention this... I use Firefox with the Adblock extension, and here are some rules found in my preferences:
This works quite well for me. I added these rules several months ago, when urchin started appearing on some web pages and making them load slower. These rules block the "urchin.js" from Google but also from other sites using their local copy of that script. The pages load faster and this makes me feel better.
The only minor issue is when I activate the FireBug extension and view Slashdot, it reports a Javascript error saying that "urchinTracker" is not defined. But this is to be expected, since the corresponding script is not loaded.
I don't think that Novell is to blame for that. On the contrary, I think that Novell has put SuSE back on the right track.
I have been using SuSE since version 4. Yes, this is a long time ago. I have tried every single version since then. This makes a nice pile of boxes.
SuSE was by far my favorite distro until about version 8.1. Then it started getting bad (broken package dependencies, too much reliance on the graphical version of YaST2 while keyboard support was half-broken in the command-line version, settings and directory hierarchies incompatible with other distros, etc.). From my point of view, versions 8.x, 9.x and 10.0 sucked compared to other distributions available at that time. Now they are becoming good again with version 10.1.
I had really lost my faith in SuSE after several bad experiences with versions 8.x and 9.x. Version 10.0 was getting better but still a bit rough around the edges. Version 10.1 is much better. I hope that version 11 will be even better and will be able to compete with other distributions such as Ubuntu in terms of polish, features and user experience. (and before you ask: no, Ubuntu is not my favorite distro although I recommend it to most people)
I bet that releasing that documentation would cost them a lot - almost as much as releasing the source code. There is no reason to think that the company internal documentation would be cleaner than the source code. They would have to get that documentation cleared by an army of lawyers and check if it contains any of their own intellectual property or any trade secrets from third parties. Then it would probably cost them to support this documentation, etc.
You are considering this from the wrong point of view. Think about it from the point of view of a company that wants to make profits. Doing what you suggest would encourage their Linux customers to keep on using obsolete cards, or maybe buy them second-hand from Windows users who have moved to more recent cards in the meantime. This would discourage these potential customers from buying their latest products and hope that a (closed source) driver is available or will be available soon.
This would be a very bad message for a company: their discontinued products (on which they cannot make profit anymore) would be competing more strongly against their current products. So it is not in their interest to release specs for anything that could still compete with their current products. They could probably do it for products that are really irrelevant now (say, 5 years old) but certainly not for products that are only 6 months old.
Note that I am playing the devil's advocate here, taking the point of view of a company interested in profit and not caring too much about being perceived as a good citizen in the tiny (but growing) open source and free software community. Alas, this is still the point of view of many companies.
There are two problems:
Having a source of noise such as a disconnected sound card or a CCD sensor in a black box can be useful in cryptography if you want to generate truly random bits. But this is not the only thing that this article is about: the signal from the quasars can be received by both parties, which provides a good one-time pad.
Well, you have a big problem with your time T. How do you know it? If you do not know the source (which quasar is used), it is also unlikely that you know the exact time T used for the start of the random stream. It is unlikely that you know it with a better precision than a few seconds. If the two parties do not exchange messages frequently or do not re-negociate the start of the random stream frequently, then you may not even know T with a precision of a day.
The NewScientistTech article does not give details about the amount of data available from the quasars, but other articles mention that quasars are typically observed in relatively high frequencies (20-40 GHz). Even if the signal strength is sampled with a low resolution and only a few truly random bits are extracted from the stream, you would still have a stream of bits that is in the Gbps range. This is a reasonably large amount of random data.
So even if the number of usable quasars is rather low (say, a few thousands: 2^10 instead of 2^32 as you mentioned), you would need a lot of antennas and petabytes of storage to record all these random streams. You would have to store something in the order of 2^40 bits per second for several seconds or even days (the uncertainty on T). This is not impossible if you have a large budget, but this is difficult and expensive.
It could even be much worse than 2^40: a recent catalogue of quasars from March 2006 mentions 85221 of them, with new findings doubling this number every second year: 48921 in 2003, 23760 in 2001, etc. Let's say that 2^15 of them are usable (and that you have 2^15 antennas at your disposal). If the signal strength is sampled with a medium resolution of 8 bits at a frequency of 30GHz and your uncertainty interval on T is about one hour, you would need to store 2^15 * 2^3 * 2^35 * 2^12 = 2^65 bits of data before starting your brute force attack. Good luck!
Once you have all this data, you still have to do the brute force attack. You wrote "just try each of the available quasar signals." This is correct but you ignore the fact that the random stream is unlikely to be used as is. It will probably be used to seed a stream cypher. In the simplest case, the random stream would be hashed a couple of times before being xor'ed with the data. You will need a huge amount of computing power to perform all these operations and try each of the available signals at each possible time offset.
Note: it is unlikely that both parties can get the signal and be synchronized with a nanosecond or picosecond resolution. So they would probably negociate a time window (say, with a resolution of one second or so) and some kind of unique marker within that time window in order to know exactly when to start. If you are the attacker and you cannot know which source is used, you probably do not know the time window nor the marker. But even in the unlikely case that you would have a way to obtain one or both of these, you would still have the problem of storing the huge amount of data from all quasars until you know which part of it should be analyzed.
So although a brute force attack based on recording all qasars is not impossible, it is not really easy. And anyway, my first reaction when I started reading this story was exactly like the comment mad
The performance can be debated, but you have got the security argument backwards. If you use pre-packaged binaries, you can get security updates quickly and automatically because any responsible Linux distributor will provide updated packages in a timely manner. This is especially useful if you maintain a large number of machines and want to make sure that the latest security patches are quickly applied to all of them.
On the other hand, compiling your own software requires you to pay attention to all security announcements and apply the security patches yourself. It may be possible to automate that to some extent (e.g., Gentoo provides some help for security patches), but not as easily as with the pre-packaged binaries.
From a security point of view, I am glad that some others are doing most of the work for me. The issue of performance can be debated because there are many pros and cons, but security is usually better for the pre-packaged binaries. Note that I am talking about security from the point of view of applying the latest security patches and staying ahead of the script kiddies, not in terms of initial configuration of the system. And by the way, I am not against compiling software on my own because I compile several packages from sources (directly from cvs or svn, especially for the stuff that I contribute to). But then I am aware that the security may actually be weaker for those packages than for the ones that I can update automatically.
This does not prevent another company (Linspire) from offering optional services on top of Ubuntu. Just like any company can offer free or non-free software that can be installed on top of Ubuntu or on top of any other Linux distribution or even any other operating system.
TWiki also includes some plug-ins that may be useful for the author of this article, such as the SyntaxHighlightingPlugin (which uses enscript as a back-end).
I am not sure that I would use a wiki for viewing source code because there are better tools for that (from viewcvs to gforge). But if you really want to, then TWiki is probably the one that has the most useful features for a corporate environment.
I would not consider this to be needless abstraction, but rather some combination of historical and practical reasons. You take the rather unlikely example of a program that would regress from a descriptive name to a project name. The project names are usually not descriptive for practical reasons: as others have pointed out, uncommon names or acronyms are more likely to be unique and less likely to conflict with other projects in the same area.
There is a plethora of programs able to edit text files (source code, etc.). If each of these projects and the corresponding binaries were called "text_editor", it would be rather hard to run the one that you want to use from the command line. It is fine to have just one or several of them listed as "Text Editor" in the desktop menus, but it is better to have a short and unique name to use from the command line. Note that there are good reasons to have more than one text editor available from the command line, even if only one of them appears in the menus (e.g., picking the best tool for a specific task, personal preferences, etc.)
Once a project starts with a unique name, it stays around because this is what the existing user base of that program expects to find. There is some inertia that prevents the project from being renamed and use a more descriptive name. So you may end up with binaries that have non-descripive names. On the other hand, most users never need to know the name of the binaries: they show up with a descriptive name in the desktop menus. Same for the installation of these programs: most package managers let the user view the packages by category. So if you want to install some application for editing images, then you go to the "Applications / Image Editing" section and then you find GIMP, Inkscape and others.
As explained above, most users do not have to care about the project names: you can simply use the descriptive names provided in the various menus. If you want to use the command line and invoke the programs directly, then it is useful to know these names but this may not even be necessary: it would be possible to provide shell aliases, wrapper scripts or symbolic links so that typing "text_editor" would start one of them or maybe tell you about the available options. So even from the command line, it would be possible to work without knowing the project names.
By the way, I agree with you that it would be nice if all projects could use intuitive names. Also, I do not like the project names that are deliberately obscure. But using intuitive names is difficult to achieve when there are several projects addressing similar needs and nobody knows in advance which one will "succeed" and will be adopted as the standard in its area (if that ever happens).
There is nothing wrong with that. Giving binaries a short name (project name or codename) means that they are easier to type. Advanced users who invoke GUI programs from the command line instead of using the menus are likely to know the project name anyway. If I use the command line, it is easier to type "gimp" than "Image Editor" or "GNU Image Manipulation Program" (note that auto-completion would not help much if you also have "Image Viewer", "Image Search", etc.).
The command line is supposed to be efficient, not descriptive. It would be impractical for the frequently used commands such as "cd", "ls", "cp" and others to have descriptive names. So it makes sense to use short names for the command line (even if they may be a bit obscure for those who do not know their origin) and use longer, more descriptive names for the desktop menus.
By the way, OSS is not the only environment that uses different names for the command line and for the menus. For example, look at the names of control panel components in Windows: descriptive names in the menus, cryptic names for the command line.
For your information, here is a direct link to the chapter of the GNOME HIG dealing with menu item names. It contains good examples of descriptive names. This was published two years ago, so any application that still uses cryptic names in the menus is violating these guidelines and should be fixed.
I think that you are confusing two things:
Of course, writing RendezVous as OneWordWithMixedCapitalization does not help. The correct spelling would be Rendez-Vous.
(End of slightly off-topic French lesson.)
In defense of jamie, ScuttleMonkey and other editors, I would say: editor's night shift != reader's night shift.
Although most of the Slashdot readers may live in the US, there is a significant percentage in Europe, Asia, Australia and other parts of the world. For them, the editor's night shift is precisely the time at which they read Slashdot.
Oops, that should have been "Chips & Dips" instead of "Chips'n Bits".
This could be explained partly by this other comment from CmdrTaco: the first submission on a given topic is more likely to be posted than the other ones, even if the other stories are written in a better way. The queue spammers submit so many stories that they are more likely to be the first ones on any given topic than many other submitters who do not have "posting stories to /." as their main hobby. Unfortunately, it does not seem to matter if the other stories are well-written or not because they were not first.
Solving this problem may require more work from the editors, because they would have to pay attention to more submissions (on a given topic) rather than stopping at the first one that look "good enough". It would also require all editors to adhere to the policy of rewarding quality over speed.
The fact that it is more of a problem now than in the early years of /. (or Chips'n Bits) is probably a side effect of the popularity of this site: getting a link published on the front page is seen as valuable by some people, so they start competing to have their story published.
Hmmm... Nitpicking, but I would prefer this version instead (note what is linked):
Otherwise, I agree with your comments.
I do not understand how this argument applies to the story selection. As an editor, you are the one who decides when you look at the stories and when you publish them. By the time you look at 5 stories that are on the same subject matter, these stories are already there (in the queue) so the time at which they were originally submitted is mostly irrelevant and will not have any influence on the time at which the story is posted.
There is currently no feedback to the submitter saying "your story has been accepted because you were the first one to submit it" or "your story has been accepted because it was well-written" or "because it had more relevant links". Similarly, there is no feedback to the ones who get rejected saying "your story has been rejected because another submission on the same topic was received earlier" or "your story has been rejected because of its lousy quality". In most cases, those who submit stories have no way to know if they were first or not. Therefore, I would argue that there is no clear incentive for submitting stories as fast as possible.
On the other hand, if we look at the feedback posted in the comments, I have seen more complaints about the quality of the stories than about the fact that other sites got the news first. This seems to indicate that it would be better to reward quality rather than speed in order to minimize the complaints and other off-topic discussions on some stories.
If I may suggest something, it would be that you try to look at all 5 stories on the same subject matter and pick the one that has the best summary or the best links rather than the one that was submitted first.
Unfortunately, that graph is rather misleading. The ext2 and ext3 filesystems keep some percentage of the disk space as "reserved" and only root can write to this reserved area. This is useful if the disk contains /var or other directories containing log files, mail queues and other stuff. Even if a normal user has filled the disk to 100%, it is still possible for some processes owned by root to store some files until an administrator can fix the problem. On the other hand, if your filesystem contains only /home or other directories in which users are not competing for disk space with processes owned by root, then it does not make much sense to have a lot of disk space reserved for root. That is why you should think about how the filesystem is going to be used when you create it, and set the amount of reserved space accordingly.
The default behavior for both ext2 and ext3 is to reserve 5% of the disk space for root. You can see it in the section Creating the Filesystems from the article:
You can change this behavior with the -m option, specifying the percentage of the disk space that is reserved. The article did not mention how the filesystem was supposed to be used if it had been used in production. However, I would guess that the option -m 0 or maybe -m 1 could have been used in this case. This would have provided a fair comparison and suddenly you would have seen all filesystems in the same range (close to 373GB available), except maybe for Reiser3.I disagree. Group #2 is probably the most important group. Keep in mind that being tainted does not only mean being exposed to Windows+Office, but also to any other desktop environment, including Linux, OS X or others.
This includes for instance the Linux FVWM users who will be frustrated that the default GNOME window manager does not offer an option to bind the mouse buttons in the "right way", or the OS X users who will be frustrated that KDE tries to copy Windows in some places and uses the "wrong" button order. Every person who reads this on Slashdot is already in group #2. The tainted users will be biased towards one environment or another, often without realizing it. So they will think that some applications will be more usable than others because of their past experience, which will strongly influence what they think is the "right" way to do things.
But being tainted does not mean being a zealot. There are many Windows users who enjoy using KDE or GNOME when they are confronted with these new environments for the first time. Even if they cannot instantly forget all their past experience with computers, they are still a very useful test group for usabilty.
I assume that you haven't tried the N770 yet. The applications are reasonably optimized for that device and from my point of view, the benefits of using X11 outweight the drawbacks. Opening a new application takes time (a few seconds) but once the application is loaded, it runs quite well. Most of the performance bottlenecks that I have hit seem to be related to the size and speed of the memory (and CPU) rather than X11.
I have developed and ported software for a large number of small devices using Windows CE, Symbian (UIQ) and now Maemo (Linux/X11/GTK+). Although Symbian is a nice OS from a conceptual point of view and is designed to perform well on resource-limited devices such as mobile phones, writing software for it is very painful. Writing for Windows CE seems to be much easier at first, but there are many gotchas: you think that you can use most of the Windows API, but then you discover that the function that you need is not supported or has some limitations forcing you to rewrite a lot of code from scratch. Writing for Maemo is a refreshing experience: of course there are some limitations, but once you have set up the Scratchbox environment, development and testing is relatively easy (compared to other mobile devices). So from a developer's point of view, the choice of the X Window System and an open distribution such as Debian is a good one.
I wouldn't mind having more memory or a more powerful CPU in this device. But as it stands now, the 770 is already a very nice gadget for web browsing, checking the news or previewing/uploading pictures taken from my mobile phone (SonyEricsson K750).