Add to that: -Conciseness Strip out the fluff for those who just want the meat.
-Separation of author opinions from the facts I want to judge things by myself first, then see what others would have to say about it afterwards, if necessary
-Context for those who need it Ability to present a concise, meaningful and accurate big-picture view for those who are encountering the subject for the 1st time
Oh and for me, accuracy comes first and foremost rather than speed. No contest.
$10/year (limited time, was $5 ~3 months ago), issued by freessl.com. Browser recognition is fairly good: IE >= 5.01, Netscape >= 7, Opera >= 7.53, Konqueror too (and thus Safari I assume, versions unknown).
Why SSL on the connection, the mail got to your server over an unencrypted connection, what's the point in starting when its already been naked in the wild?
With SSL, both your username and your password are transmitted encrypted. A major draw for paranoids everywhere.
A low-grade certificate from Thawte or another provider should cost you less than $100 and will put a significant (though still not foolproof) hurdle in the way. Just get one already.
You can a certificate at much cheaper than $100. Instantssl.com offers certs at $49 per year. Its browser coverage (i.e. how many browsers are distributed with its public key) is also good at a reported 99.3%. I once found another certificate provider at $39/year (but with lower browser coverage) but I forgot the address. Do a search and you'll probably find it. Personally I think the price is well worth it for the added security and peace of mind that it provides, but since icarusindie.com is providing a free service you understandably might not want to spend too much on it. BTW how are you paying for that webmail thing? Do you plan to stick around or will you get bored and shut down the thing after some time?
But this is where things get problematic. Whenever a developer tries
to anticipate what the user expects and write around those expectations, they
naturally have to impose some restraints upon the system. And the real problem
is this: different users expect different things. Pretty soon, those restraints start
getting in the way.
Different users expect different things, that's true. But there are always a set
of common expectations associated with every application type that exists. If I
download a mail client, I expect to be able to read and respond to my mail with it.
If I download what purports to be a word processor, I expect to manage to type a letter
with it. And so on. What an app designer should do is to make those very basic and
very easily anticipatable tasks easy and convenient to perform. Doing so will never
complicate matters at all. What should _not_ be done is to try to anticipate every
possible combination of actions that a user might want to perform and place a button
on the toolbar for it or a menu entry or a command or whatnot. Now _that_ would complicate
things and the restraints you are talking about would start to be felt.
Furthermore, if one creates an asbtraction or a model for performing a particular task,
it is only good design to create it so that there are no arbitrary limitations imposed,
and that one does not break the abstraction unnecessarily. Hence what I was saying: the
ports tree is a mechanism for program installation. Not being able to treat the ports tree
itself as an app to be updated, with an adjustable level of granularity if needed (for
example being able to update a subtree), is a break with the abstraction created that
only serves to highlight the shortsightedness of its creators. (In fairness, the original
idea itself is cool and I was delighted when I first used it to see it in action. Its
only that the people who did it didn't think ahead far enough). Another break with the
abstraction is that ports is used only for a particular category of apps.
On the contrary, I think such a concept shows a lack of vision. There are over 8000 applications in the ports tree. Is it reasonable to assume that every admin, on every machine, would want to track every port?
Please. Have I ever talked about always tracking every port that's out there? What I'm saying
is you should be able to cd into any subdirectory, or the root ports-directory, and update that.
Rather, the ports system is designed so that the admin can decide to track a specific group of applications on a specific machine.
Designed? It's all done by exchannel means, bringing in other apps and methods that's foreign to the ports concept. For God's sake.
I think you're missing the elegance of the system, and the beauty of the design.
The ports system _is_ elegant and beautiful, only I'm saying it could have been more so.
Ports are applications that are outside of the core, maintained OS. I can upgrade any port or combination of ports without worrying about dependency issues with the core system. I can upgrade the core system without worrying about breaking the ports.
Hmmm. Apps in the ports tree depend on the core. They depend on things like the libc and the kernel. Isn't there the possiblility that updating these could break apps built from ports?
Regardless, that's tangential to what I'm talking about. I'm saying that a very
nice program-installation mechanism was built. It could have trivially been extended to cover
much more, like Debian and Gentoo have done. Instead it was unnecessarily limited
in its scope.
I can selectively synch specific parts of the ports or source trees. It is very flexible, but because of that flexibility there isn't a one-size-fits-all way of doing things (which is why cvsup comes with a collection of sample supfiles).
What I'm proposing is as at least as flexible, and the major advantage is that it doesn't
break with the standard way of
It isn't about "old school" or "new school". It's about having a system that's prepared for the _common_ and _expected_ tasks that a user might want to do and right out the box is prepared to do them without much fuss. It is totally expected that at some point one would want to update the whole ports tree. Being able to treat the ports tree itself as a mere package would tend to indicate that the designers of the ports system have thought the whole problem through, and are applying the standard program-installation infrastructure that they themselves built to itself. It's a mark of a well thought-out system. Kind of like "everything is a file" in Plan9. Contrast that with Unix, where the idea is taken only so far and then you get a totally different namespace for network stuff. Jarring and inelegant. Same stuff here: You use ports for most every app, but not the ports tree itself (and also not the base system).
The best course of action when designing an app is to make the common tasks simple (ideally no further configuration needed), but give enough power and flexibility so that the uncommon ones too are possible (I'm not a fan of denying power to users).
It's probably due to that bug whereby the uptime counter wraps around after 497 days and a few timesteps later. From what I gather, there are people who are working to get that bug squashed but I dunno if their patches have been accepted by Linus. See also this page from Netcraft explaining the potential problems about their method of uptime detection. You'll also learn there that some OSes do not report uptime, among them such "enterprise" favorites as AIX, Tru64, VM, OS/390 and others. So Netcraft's stuff, while interesting, is not a definitive comparison of the relative stability of the various server OSes out on the Net.
Every once in a while XFree86 Will completly crash on me with no way of accessing Linux (Including telnet). In a sence it locked up. Wile I never had that problem with Solaris.
Well, it did happen to me once on a Sun machine runnning Solaris. Everything froze and no way to telnet in. Sun is not God's Own Computer Company and their stuff is not immune from such occurrences.
It's ALSA's fault: read this message by Robert Love, the preemtible-kernel-patch's author. The guy who reported this problem later switched to OSS/Free and the latency problems were gone.
Language does not evolve by a small group of wannabe intellectuals accidentally using a latin
pleuralisation due to not realising that the language already has an established pleural for that
word, and then claiming it was not an error but a deliberate change to differentiate a certain
kind of box from all those other identical boxes
The -en pluralisation is not a latin one but an Old English one. You can see it in words such as "oxen" and "children". But I agree that differentiating meaning through an unconventional plural form is rather silly. This results in the kludge that the singular form is not differentiable.
You're conveniently forgetting one thing: the Detroiters' cars were _engineered_ to fail within certain specific timespans, in a doomed and (and ultimately self-destructive) desire to get the consumer to purchase a new machine a few years down the line. Now, don't you notice a resemblance to the tactics that a certain duopoly had been practising with awesome vigor up until a few moons back? Please tell me you do.
Yeah that's better.
That's what poeple think of when comparing the Japanese Car Effect with the current computer industry.
<BR>
He might not have been (are you him BTW? Just a question:)), but looking around this thread, there are plenty of others who are doing so, on both "sides". It's amazing how many people are so bigoted about 2 free OSes and don't make much effort to be fair-minded. Here we have to high-quality, free systems, and all some people care is to engage in a foul-mouthed pissing contest. Then again, knowing human nature this isn't so surprising.
The Internet Archive (www.archive.org) uses FreeBSD as the OS for its 10+ terabyte disk farm
Thanks for that link, I had never heard of that site before. But your information appears to be outdated:
- This link says that they use Linux to store all that data (with IDE hard drives, it's specified).
- This link says they use Linux for both access to the data (via ssh) and storage.
What exactly do these provide that's missing in Linux? I don't have the inclination to drudge through all those crosslinked man pages, so a little summary would be nice from somebody who knows about this stuff.
NAME ata, acd, ad, afd, ast - Generic ATA/ATAPI disk
controller driver
[...]
bash-2.03$ ls -l/usr/share/man/man4 | wc -l 261 bash-2.03$
Damn cool, I love it (except for the fact that man pages are something
stuck in the 70s, a new cross-*nix standard needs to be defined).
I just wish somebody would put as much care into creating such a distro
for linux, one which didn't have the cobbled-together, DIY feel that I
usually get with linux distros. Apparently, Debian is the one which
comes the closest to FreeBSD in these departments, I should be get off
my backside and install it one of these days. As you say, it requires
closer integration of the kernel and userland, something which just
isn't happening on the linux side, and which isn't likely to happen
considering how the development of the kernel and other bits and pieces
are all separate and utterly chaotic. It does seem to me that FreeBSD
people take a much more profesional approach than most linux distros,
spending less time on the flashy stuff, and more time on making the
whole system appear as a coherent entity. To those in the know:
How does Debian compare to FreeBSD in terms of integration and attention
to detail, for example consistency of utilities, presence of man pages and their 'uptodateness'? I'd really like to know.
Anyway, I hope to be installing both of those systems sometime in the
future and play around with them.
Maybe because a depending package with a greater version number might incorporate new features and design changes, which might cause the main package to break
As you say, it might. If you know that package foo, currently at R27 v2.3.90, is okay with your lil' proggy way back from R23 v3.40.9, you don't force the poor sod who's installing your package to have to upgrade his perfectly okay foo to satisfy your dependencies. If you don't know that, then you simply don't say so in your package. Point is: such a feature has its uses. Don't try to cover up deficiencies by pretending that such possbilities don't exist. You see a good idea that you don't have in your current kickass world-beating utterly purrrfect system, don't turn up your nose at it (and then a few months later implementing it on the sly). Acknowledge it and borrow it. Nobody's perfect, we can all learn from one another, and we'll all be better off that way.
Drag-and-drop is implemented intelligently in KDE. Drag something to a folder or to the desktop, and you are presented with a Move/Copy/Link option EVERY TIME. That's so beautiful I could cry. I hate guessing when Windows wants to move, copy, or make a shortcut to a file.
Same can be done in Windows too: right-click-drag,
and when you release the mouse button, you're presented with a menu asking you what you want to do, same as in KDE, and it's been there since Win95. If you happen to have memorized the default action of the drag operation, you can simply left-click-drag and be done with it. For example, IIRC, left-click-dragging an executable would produce a shortcut to it. It's better than in KDE1 since both experts and newbies will find satisfaction. But generally I agree with you that KDE and Gnome are not pure copies of Windows and have done some valuable design on their own, unlike what most uninformed (and frequently loud-mouthed and smart-aleckish) people around here seem to assume.
I don't know if it is a real question or only rethoric. Let's say it is a real question. <BR><BR>
It was a real question. Thanks for your answer.
Sadly, it seems that if Mozilla or derivatives were to become the only decent browser(s) on Linux, low-end machines have no future as desktops, not if you want to make any heavy use of the web anyway. I still harbour hope that it'll get optimised to acceptability by some perrformance-hungry hackers, but I'm not holding my breath.
>It is still visually ugly, have a slow interface >(but a fast rendering),
I'd really like to know what the fsck they've done to make the interface sooooo slow. Is it that difficult to write a an interface that doesn't make you lose patience while waiting for it or what? IMO that unwelcome "feature", the subjective feel of it, the sense of wading in molasses (I've got an antique of a PC right now) is really offputting.
Slashdot Mirror
Access times are where flash takes the advantage. IIRC, it's ~50 ns for flash v/s ~10 ms for hard disks, thus in the order of 200,000 times faster
>Ego
Just one of an infinite number possible reasons. The metareason is:
These "smart people" are not "smart" in all circumstances.
Add to that:
-Conciseness
Strip out the fluff for those who just want the meat.
-Separation of author opinions from the facts
I want to judge things by myself first, then see what others would have to say about it afterwards, if necessary
-Context for those who need it
Ability to present a concise, meaningful and accurate big-picture view for those who are encountering the subject for the 1st time
Oh and for me, accuracy comes first and foremost rather than speed. No contest.
It's at ev1ervers.net.
$10/year (limited time, was $5 ~3 months ago), issued by freessl.com. Browser recognition is fairly good: IE >= 5.01, Netscape >= 7, Opera >= 7.53, Konqueror too (and thus Safari I assume, versions unknown).
With SSL, both your username and your password are transmitted encrypted. A major draw for paranoids everywhere.
You can a certificate at much cheaper than $100. Instantssl.com offers certs at $49 per year. Its browser coverage (i.e. how many browsers are distributed with its public key) is also good at a reported 99.3%. I once found another certificate provider at $39/year (but with lower browser coverage) but I forgot the address. Do a search and you'll probably find it. Personally I think the price is well worth it for the added security and peace of mind that it provides, but since icarusindie.com is providing a free service you understandably might not want to spend too much on it. BTW how are you paying for that webmail thing? Do you plan to stick around or will you get bored and shut down the thing after some time?
But this is where things get problematic. Whenever a developer tries to anticipate what the user expects and write around those expectations, they naturally have to impose some restraints upon the system. And the real problem is this: different users expect different things. Pretty soon, those restraints start getting in the way.
Different users expect different things, that's true. But there are always a set of common expectations associated with every application type that exists. If I download a mail client, I expect to be able to read and respond to my mail with it. If I download what purports to be a word processor, I expect to manage to type a letter with it. And so on. What an app designer should do is to make those very basic and very easily anticipatable tasks easy and convenient to perform. Doing so will never complicate matters at all. What should _not_ be done is to try to anticipate every possible combination of actions that a user might want to perform and place a button on the toolbar for it or a menu entry or a command or whatnot. Now _that_ would complicate things and the restraints you are talking about would start to be felt.
Furthermore, if one creates an asbtraction or a model for performing a particular task, it is only good design to create it so that there are no arbitrary limitations imposed, and that one does not break the abstraction unnecessarily. Hence what I was saying: the ports tree is a mechanism for program installation. Not being able to treat the ports tree itself as an app to be updated, with an adjustable level of granularity if needed (for example being able to update a subtree), is a break with the abstraction created that only serves to highlight the shortsightedness of its creators. (In fairness, the original idea itself is cool and I was delighted when I first used it to see it in action. Its only that the people who did it didn't think ahead far enough). Another break with the abstraction is that ports is used only for a particular category of apps.
On the contrary, I think such a concept shows a lack of vision. There are over 8000 applications in the ports tree. Is it reasonable to assume that every admin, on every machine, would want to track every port?
Please. Have I ever talked about always tracking every port that's out there? What I'm saying is you should be able to cd into any subdirectory, or the root ports-directory, and update that.
Rather, the ports system is designed so that the admin can decide to track a specific group of applications on a specific machine.
Designed? It's all done by exchannel means, bringing in other apps and methods that's foreign to the ports concept. For God's sake.
I think you're missing the elegance of the system, and the beauty of the design.
The ports system _is_ elegant and beautiful, only I'm saying it could have been more so.
Ports are applications that are outside of the core, maintained OS. I can upgrade any port or combination of ports without worrying about dependency issues with the core system. I can upgrade the core system without worrying about breaking the ports.
Hmmm. Apps in the ports tree depend on the core. They depend on things like the libc and the kernel. Isn't there the possiblility that updating these could break apps built from ports?
Regardless, that's tangential to what I'm talking about. I'm saying that a very nice program-installation mechanism was built. It could have trivially been extended to cover much more, like Debian and Gentoo have done. Instead it was unnecessarily limited in its scope.
I can selectively synch specific parts of the ports or source trees. It is very flexible, but because of that flexibility there isn't a one-size-fits-all way of doing things (which is why cvsup comes with a collection of sample supfiles).
What I'm proposing is as at least as flexible, and the major advantage is that it doesn't break with the standard way of
It isn't about "old school" or "new school". It's about having a system that's prepared for the _common_ and _expected_ tasks that a user might want to do and right out the box is prepared to do them without much fuss. It is totally expected that at some point one would want to update the whole ports tree. Being able to treat the ports tree itself as a mere package would tend to indicate that the designers of the ports system have thought the whole problem through, and are applying the standard program-installation infrastructure that they themselves built to itself. It's a mark of a well thought-out system. Kind of like "everything is a file" in Plan9. Contrast that with Unix, where the idea is taken only so far and then you get a totally different namespace for network stuff. Jarring and inelegant. Same stuff here: You use ports for most every app, but not the ports tree itself (and also not the base system).
The best course of action when designing an app is to make the common tasks simple (ideally no further configuration needed), but give enough power and flexibility so that the uncommon ones too are possible (I'm not a fan of denying power to users).
It's probably due to that bug whereby the uptime counter wraps around after 497 days and a few timesteps later. From what I gather, there are people who are working to get that bug squashed but I dunno if their patches have been accepted by Linus. See also this page from Netcraft explaining the potential problems about their method of uptime detection. You'll also learn there that some OSes do not report uptime, among them such "enterprise" favorites as AIX, Tru64, VM, OS/390 and others. So Netcraft's stuff, while interesting, is not a definitive comparison of the relative stability of the various server OSes out on the Net.
Well, it did happen to me once on a Sun machine runnning Solaris. Everything froze and no way to telnet in. Sun is not God's Own Computer Company and their stuff is not immune from such occurrences.
It's ALSA's fault: read this message by Robert Love, the preemtible-kernel-patch's author. The guy who reported this problem later switched to OSS/Free and the latency problems were gone.
The -en pluralisation is not a latin one but an Old English one. You can see it in words such as "oxen" and "children". But I agree that differentiating meaning through an unconventional plural form is rather silly. This results in the kludge that the singular form is not differentiable.
> and the implementation of games thereof.
Er, games of subdivision? I think the word you're looking for is "therewith".
OK, I'll fuck off now.
>How did you check the bandwidth on kernel.org?
The site's bandwidth utilisation is usually listed on its home page.
>I've never heard of a tool that does that, but
> would be interested to learn about one.
Never heard about such a thing myself.
You're supposed to be able to write... You've been writing for how long? No I'm not a born anglophone.
Oh fuck it, I'm dead tired. Ignore that post. Sorry.
You're conveniently forgetting one thing: the Detroiters' cars were _engineered_ to fail within certain specific timespans, in a doomed and (and ultimately self-destructive) desire to get the consumer to purchase a new machine a few years down the line. Now, don't you notice a resemblance to the tactics that a certain duopoly had been practising with awesome vigor up until a few moons back? Please tell me you do.
Yeah that's better.
That's what poeple think of when comparing the Japanese Car Effect with the current computer industry.
Open your eyes my friend.
I don't think he was "pretending" anything.
:)), but looking around this thread, there are plenty of others who are doing so, on both "sides". It's amazing how many people are so bigoted about 2 free OSes and don't make much effort to be fair-minded. Here we have to high-quality, free systems, and all some people care is to engage in a foul-mouthed pissing contest. Then again, knowing human nature this isn't so surprising.
<BR>
He might not have been (are you him BTW? Just a question
The Internet Archive (www.archive.org) uses FreeBSD as the OS for its 10+ terabyte disk farm
Thanks for that link, I had never heard of that site before. But your information appears to be outdated:
- This link says that they use Linux to store all that data (with IDE hard drives, it's specified).
- This link says they use Linux for both access to the data (via ssh) and storage.
So it appears that they've switched OSes.
What exactly do these provide that's missing in Linux? I don't have the inclination to drudge through all those crosslinked man pages, so a little summary would be nice from somebody who knows about this stuff.
I also love FreeBSD for this:
/usr/share/man/man4 | wc -l 261 bash-2.03$
bash-2.03$ man ata
ATA(4) FreeBSD Kernel Interfaces Manual ATA(4)
NAME ata, acd, ad, afd, ast - Generic ATA/ATAPI disk controller driver
[...]
bash-2.03$ ls -l
Damn cool, I love it (except for the fact that man pages are something stuck in the 70s, a new cross-*nix standard needs to be defined).
I just wish somebody would put as much care into creating such a distro for linux, one which didn't have the cobbled-together, DIY feel that I usually get with linux distros. Apparently, Debian is the one which comes the closest to FreeBSD in these departments, I should be get off my backside and install it one of these days. As you say, it requires closer integration of the kernel and userland, something which just isn't happening on the linux side, and which isn't likely to happen considering how the development of the kernel and other bits and pieces are all separate and utterly chaotic. It does seem to me that FreeBSD people take a much more profesional approach than most linux distros, spending less time on the flashy stuff, and more time on making the whole system appear as a coherent entity. To those in the know: How does Debian compare to FreeBSD in terms of integration and attention to detail, for example consistency of utilities, presence of man pages and their 'uptodateness'? I'd really like to know.
Anyway, I hope to be installing both of those systems sometime in the future and play around with them.
Maybe because a depending package with a greater version number might incorporate new features and design changes, which might cause the main package to break
:)
As you say, it might. If you know that package foo, currently at R27 v2.3.90, is okay with your lil' proggy way back from R23 v3.40.9, you don't force the poor sod who's installing your package to have to upgrade his perfectly okay foo to satisfy your dependencies. If you don't know that, then you simply don't say so in your package. Point is: such a feature has its uses. Don't try to cover up deficiencies by pretending that such possbilities don't exist. You see a good idea that you don't have in your current kickass world-beating utterly purrrfect system, don't turn up your nose at it (and then a few months later implementing it on the sly). Acknowledge it and borrow it. Nobody's perfect, we can all learn from one another, and we'll all be better off that way.
Drag-and-drop is implemented intelligently in KDE. Drag something to a folder or to the desktop, and you are presented with a Move/Copy/Link option EVERY TIME. That's so beautiful I could cry. I hate guessing when Windows wants to move, copy, or make a shortcut to a file.
Same can be done in Windows too: right-click-drag, and when you release the mouse button, you're presented with a menu asking you what you want to do, same as in KDE, and it's been there since Win95. If you happen to have memorized the default action of the drag operation, you can simply left-click-drag and be done with it. For example, IIRC, left-click-dragging an executable would produce a shortcut to it. It's better than in KDE1 since both experts and newbies will find satisfaction. But generally I agree with you that KDE and Gnome are not pure copies of Windows and have done some valuable design on their own, unlike what most uninformed (and frequently loud-mouthed and smart-aleckish) people around here seem to assume.
I just do a 'rpm -qa' on Redhat, but I have no idea what the equivalent on Debian is.
dpkg --list
I don't know if it is a real question or only rethoric. Let's say it is a real question.
<BR><BR>
It was a real question. Thanks for your answer.
Sadly, it seems that if Mozilla or derivatives were to become the only decent browser(s) on Linux, low-end machines have no future as desktops, not if you want to make any heavy use of the web anyway. I still harbour hope that it'll get optimised to acceptability by some perrformance-hungry hackers, but I'm not holding my breath.
>It is still visually ugly, have a slow interface >(but a fast rendering),
I'd really like to know what the fsck they've done to make the interface sooooo slow. Is it that difficult to write a an interface that doesn't make you lose patience while waiting for it or what? IMO that unwelcome "feature", the subjective feel of it, the sense of wading in molasses (I've got an antique of a PC right now) is really offputting.