While many OpenID implementations may leave something to be desired from a usability point of view, I think you are completely seeing this the wrong way.
``You can't possibly expect him to do something as complex as reading up on what OpenID is, signing up for an OpenID account on a totally different website that has got nothing to do with the original website that he was on, and then logging in by entering a long magical URL.''
This is exactly why OpenID is a Good Thing. Once signed up, you don't have to go through that hassle ever again for sites that support OpenID. How involved it is to actually sign up for and use OpenID with any particular site is a different issue - OpenID specifies a protocol; you can build your own user interface.
As for "long magical URL"; I don't think it need be any harder to remember than an email address. Certainly, it can be no harder than remember a telephone number, which everybody used to do back in the day. I fully agree that if we can improve usability, we should, but it's not like OpenID is impossible to use for "People like him - average users" as it is.
``As we add complexity and layers of abstraction things tend to slow down in general. If hardware keeps up, and actual human productivity increases, do we have an issue?''
You have that exactly right. Software getting slower is bad, but it's ok if it is offset by other changes, such as faster hardware or new, more efficient ways to perform tasks. In the end, it's our productivity that counts. Now the real question is, how do we measure that, how has it developed over time, and what changes have had the greatest impact (both positive and negative) on it?
You make it sound like it is inevitable and acceptable that newer software is slower than older software. I disagree. For one thing, one way to improve software is to make it faster. This is actually done sometimes. Secondly, even if you add features to software (which is another way to improve software), that doesn't have to make the software slower. In some cases, this may be inevitable, but in many cases it is not.
I personally see computers, and software, as tools for making life more efficient. When software becomes slower, efficiency is actually lost. When this isn't offset by providing me with a more efficient work flow, I lose efficiency. Since efficiency is the main reason I use computers in the first place, this is a big deal.
``Obviously, we must stop using using pansy C/C++/Java/Ruby/etc... languages and go back to writing everything in assembler. Then boot times will rock!''
Well, yeah. Most of the boot time of my machine, aside from the POST that the OS has no control over, is taken up by shell scripts. Switching to a faster shell improves boot time significantly. Of course, even that shell isn't very fast, compared to replacing the shell scripts by optimized machine code.
I am not saying that replacing the boot scripts by assembly code is a good idea, but as far as boot time goes, there is quite some room for improvement.
Also, I think I should mention MenuetOS here, as it's written in assembly and pretty efficient.
``Changing the old bios with something new would help boot times a lot!''
And please, no EFI. EFI is just an incompatible and (from what I've seen) under-featured Open Firmware knock-off. If you want something Open-Firmware-like, better just use the real thing. And if you want something else, there's coreboot, which is open, gives you lots of flexibility, can be really fast, and actually can be used to provide Open Firmware, too. I really think coreboot is the way to go.
``When I tell my PC to shut down, all it really needs to do is make sure that no files are currently being written to disk, force a dismount of all drives, and then cut the power.''
That's pretty much how it works on OpenBSD and NetBSD (at least when I used them). They do run/etc/rc.shutdown, but that script generally doesn't do very much. So you are right: much of what other systems do on shutdown is unnecessary and a waste of time.
If you really want to shut down your system quickly, I guess you could use halt -f or shutdown -n, but I'm not sure that would be a good idea, because it really won't run any shutdown scripts at all, as far as I understand.
My system used to boot quickly enough for my tastes, until I enabled disk quota. Now, when I have an unclean shutdown (and I hardly ever have clean ones), the system spends several _hours_ running quotacheck. Isn't there some way to reduce this? I read something that suggests there are journalled quota nowadays, but how do they work and which filesystems are supported?
``How is it that the more power we get, the -longer- this takes? And why is it that the solution always involves hardware makers? Maybe we need to look at how our operating systems are constructed instead of blaming the hardware itself.''
The time it takes to start up a computer is mostly determined by the firmware. Once the software has control of the system, you can boot an OS very quickly (Linux in a few seconds). But before the software gets to run, the firmware has control of the system. I've seen computers where the firmware would perform initialization and self tests for several minutes. If you were to replace the firmware with something else (e.g. coreboot), you could go from power up to ready to use in a few seconds. But it's usually the hardware makers who decide what firmware to ship. And that's why it's up to them to improve things.
This is about the umpteenth time we hear about this. Somehow, I can't believe anymore that putting these chips in passports was meant to increase security. The question is...what _was_ the purpose?
``A comment indicitive of someone who lives relatively close to the equator. For those of us who see a 6-12 hour difference in the number of daylight hours it can make a real difference.''
I don't see that. How does shifting the clock time by 1 hour offset 6-12 hours of difference in daylight?
I live at 52 degrees latitude, in a country that does DST, and I hate it. It's not just people who forget about the clock change and show up an hour late or early. It's also the confusion that ensues from clock time not being continuous. And there's no way out...you can record times so that they are continuous, but then people get confused because the recorded time doesn't match clock time.
Personally, I think DST is an abomination and should be abolished. And, while we're at it, let's think hard about time zones, too.
``(Actually, that's one of the things that pisses me off most about the party-based government systems: you can't vote for specific policies, you either pick the Liberal package, or the Labor package (Labour/Tory, Dem/GOP, whatever).''
s/party-based/two-party/
The problem here is that you only have two realistic choices. Any vote that isn't for a large party is likely lost. Some countries have a system of proportional representation. This allows you to vote for the party you like best, and the more people who do so, the more influence that party will have on policy. You don't have to pick the lesser of two evils to prevent the greater from coming to power.
I was actually under the impression that Australia had a multi-party system with proportional representation. Is this not the case?
While I haven't actually thought out a solution to the real problems related to child pornography, I feel the very least we can do is stop making the innocent and harmless suffer for it.
No solution is better than a "solution" that does more harm than good.
``Shai Agassi is a smart and charismatic man, but who can really say they're happy with the cell phone business model? Most consumers aren't, but the cellular networks are making quite a profit.''
I'm not complaining. I get to make and receive phone calls and text messages and access the Internet pretty much everywhere I go, for less money than my ADSL line costs.
DRM and open-source do not go together. They can't. If it is open-source, you can circumvent the restrictions. You can simply look at the code and change it so that it accepts whatever you want to do. Even if they depend on some information you get from a system that isn't under your control. You do it once, and then you can get at the content, and then you can decode the content, and then you can do whatever you want with it.
Conversely, if you cannot alter the software to disable the restrictions, it's not open source.
Having said that, I suppose it is possible to slap an open source license on your software, and still have users be legally disallowed from circumventing the DRM that is in your software.
Your points are all well taken, and I fully agree with your comments on HTML.
That leaves me with one question. Is Silverlight an open standard? Can I go and write my own implementation for my own platform and under my own license, and create a full implementation that can run any Silverlight app that has been coded to the standard, without having to fear lawsuits from Microsoft for infringing on their intellectual property?
When reading this, I couldn't help but wish _I_ got paid that much money. The figure I get from sloccount ($55K) seems high, but this is even higher than that! Anybody want to make me an offer?
``Unfortunately, as you approach the limit, the performance must drop as you've now abstracted so far that your code becomes essentially a virtual machine on which your data runs.''
I don't see that. Not all abstraction makes things slower. In many cases, abstraction lets you write code at a higher level, while still compiling down to the code you would have written if working at a lower level.
> Journalling, by its very nature, implies turning every write into two writes.
First of all, that isn't necessarily true; I think Log-structured Filesystem) is one example of a filesystem that uses a journal, yet does not write everything twice. It also depends on how much consistency you want to maintain: many journalled filesystems have the option to journal structure, but not data. Secondly, extra writes don't necessarily cause a performance hit. It all depends on the usage patterns. If the writes can be performed when the disk would otherwise be idle, no performance is lost.
> > But one advantage of having a journal is that you can maintain consistency > > even if you suffer a failure in the middle of a write. > This is relevant and interesting if you are running a bank. It is completely uninteresting if you spend your day > writing text files and compiling them, like I do.
Right. Different jobs, different tools.
> > If you claim that compressed archives are more efficient for storing many small files, you had > > better actually know at least one compressed archive format that actually is more efficient. > > Otherwise, you would just be making an unfounded claim. Again, I ask you to back up your claims. > What sort of foundation would you like to hear?
Anything that justifies your claim of compressed archives storing many small files more efficiently than any filesystem.
> I would consider it obvious for the simple reason that compressing a hundred files into an archive > will always take less space than a hundred uncompressed files, no matter how efficiently they may > be aggregated.
So you meant "space-efficient". I thought we were talking about time-efficiency. Ok, fair enough. But what if the filesystem compressed the files, as well?
> While you can compress the entire filesystem, that is usually not a good idea, because there is no > generic way to determine which files should be compressed and which ones should not.
True, but the same goes for archive files, of course. Any metric that the archiver uses to determine which files should be compressed, the filesystem can use, too.
I think I see what you're getting at, though. The filesystem exposes a certain programming interface. Traditionally, this interface does not give applications a lot of control. For example, the application might know which files should be compressed, and which ones shouldn't, but the VFS does not typically allow this information to be communicated to the filesystem. A purpose-built storage system specific to the particular application could, of course, incorporate anything and everything that might be useful.
> First of all, I do not think that allowing the user to muck with application internal files with > "standard tools" is a good idea.
Well, see, generalizations. In some cases, there is no significant gain to being able to use standard tools to manipulate some data. In that case, feel free to lump all that data together in a single file that only your application knows how to deal with. But that wasn't the case I was talking about. I was talking about the case where you have pieces of data that are meaningful to the user, like individual emails. I thought that was what you were talking about, as well. I'm certainly not proposing every byte of the email should be in its own file. But I can see where having a one-to-one correspondence between emails and files, and perhaps even email parts to files, or even email headers to files, would be useful. You seem to be arguing I shouldn't want to do this, because filesystems are bad at dealing with such small parts - I say, filesystems can be made to be good at this, let's do it! And _then_ we can decide if having a file per email header is a good idea or not.
> you aren't planning to tell all your users that they must use ReiserFS to use your ap
``Unfortunately, a lot of managers see "free" software and dive on that not understanding that they need people to maintain/support that.''
That's probably because they have people on staff who are supposed to maintain/support the software the company uses. Of course these people won't magically be able to support whatever others decide to throw at them, but that is the case regardless of whether the software is open-source or not. And the solution is the same as always: either get your people to learn the new software, or hire new people who already know.
Apparently, extra costs during normal operation, and extra costs in the event of failure, where you have to sit and wait for the support provider to diagnose the problem. And then maybe a free fix, if the provider decides that this is covered under their contract with you.
By contrast, without the vendor support, you have no extra cost during normal operation, and some of the people who would, in the vendor support scenario, be twiddling thumbs during downtime would instead be diagnosing and fixing the problem. And then you would have to pay for the fix.
There are a couple of scenarios where vendor support wins. For example, it could reduce your costs during normal operation, because your people don't need to be qualified to diagnose all possible problems - after all, that's what you have vendor support for. By the same token, if your people aren't as good at diagnosing problems as the vendor's people, vendor support may win in the event of problems, because they get diagnosed and fixed faster.
On the other hand, I prefer just having people who know the system well enough that they can anticipate and diagnose problems, and have spare parts on hand to deal with hardware failures. That way, I don't have to depend on a vendor for support, I don't have to pay the vendor for it, and I don't have to wait for the vendor to provide the support.
Slashdot Mirror
While many OpenID implementations may leave something to be desired from a usability point of view, I think you are completely seeing this the wrong way.
``You can't possibly expect him to do something as complex as reading up on what OpenID is, signing up for an OpenID account on a totally different website that has got nothing to do with the original website that he was on, and then logging in by entering a long magical URL.''
This is exactly why OpenID is a Good Thing. Once signed up, you don't have to go through that hassle ever again for sites that support OpenID. How involved it is to actually sign up for and use OpenID with any particular site is a different issue - OpenID specifies a protocol; you can build your own user interface.
As for "long magical URL"; I don't think it need be any harder to remember than an email address. Certainly, it can be no harder than remember a telephone number, which everybody used to do back in the day. I fully agree that if we can improve usability, we should, but it's not like OpenID is impossible to use for "People like him - average users" as it is.
``Sure, the kids were doing something they should not''
Actually, is trying to break into supposedly secure areas and reporting any flaws you find to those in charge really something one should not do?
``As we add complexity and layers of abstraction things tend to slow down in general. If hardware keeps up, and actual human productivity increases, do we have an issue?''
You have that exactly right. Software getting slower is bad, but it's ok if it is offset by other changes, such as faster hardware or new, more efficient ways to perform tasks. In the end, it's our productivity that counts. Now the real question is, how do we measure that, how has it developed over time, and what changes have had the greatest impact (both positive and negative) on it?
You make it sound like it is inevitable and acceptable that newer software is slower than older software. I disagree. For one thing, one way to improve software is to make it faster. This is actually done sometimes. Secondly, even if you add features to software (which is another way to improve software), that doesn't have to make the software slower. In some cases, this may be inevitable, but in many cases it is not.
I personally see computers, and software, as tools for making life more efficient. When software becomes slower, efficiency is actually lost. When this isn't offset by providing me with a more efficient work flow, I lose efficiency. Since efficiency is the main reason I use computers in the first place, this is a big deal.
``Obviously, we must stop using using pansy C/C++/Java/Ruby/etc... languages and go back to writing everything in assembler. Then boot times will rock!''
Well, yeah. Most of the boot time of my machine, aside from the POST that the OS has no control over, is taken up by shell scripts. Switching to a faster shell improves boot time significantly. Of course, even that shell isn't very fast, compared to replacing the shell scripts by optimized machine code.
I am not saying that replacing the boot scripts by assembly code is a good idea, but as far as boot time goes, there is quite some room for improvement.
Also, I think I should mention MenuetOS here, as it's written in assembly and pretty efficient.
``Changing the old bios with something new would help boot times a lot!''
And please, no EFI. EFI is just an incompatible and (from what I've seen) under-featured Open Firmware knock-off. If you want something Open-Firmware-like, better just use the real thing. And if you want something else, there's coreboot, which is open, gives you lots of flexibility, can be really fast, and actually can be used to provide Open Firmware, too. I really think coreboot is the way to go.
``When I tell my PC to shut down, all it really needs to do is make sure that no files are currently being written to disk, force a dismount of all drives, and then cut the power.''
That's pretty much how it works on OpenBSD and NetBSD (at least when I used them). They do run /etc/rc.shutdown, but that script generally doesn't do very much. So you are right: much of what other systems do on shutdown is unnecessary and a waste of time.
If you really want to shut down your system quickly, I guess you could use halt -f or shutdown -n, but I'm not sure that would be a good idea, because it really won't run any shutdown scripts at all, as far as I understand.
My system used to boot quickly enough for my tastes, until I enabled disk quota. Now, when I have an unclean shutdown (and I hardly ever have clean ones), the system spends several _hours_ running quotacheck. Isn't there some way to reduce this? I read something that suggests there are journalled quota nowadays, but how do they work and which filesystems are supported?
``How is it that the more power we get, the -longer- this takes? And why is it that the solution always involves hardware makers? Maybe we need to look at how our operating systems are constructed instead of blaming the hardware itself.''
The time it takes to start up a computer is mostly determined by the firmware. Once the software has control of the system, you can boot an OS very quickly (Linux in a few seconds). But before the software gets to run, the firmware has control of the system. I've seen computers where the firmware would perform initialization and self tests for several minutes. If you were to replace the firmware with something else (e.g. coreboot), you could go from power up to ready to use in a few seconds. But it's usually the hardware makers who decide what firmware to ship. And that's why it's up to them to improve things.
``audio and video compatible SIP client''
Hasn't Ubuntu had that for ages? As far back as I can remember, Ubuntu has always included Ekiga.
I wonder how many stars it will score on the crash test ...
I felt these links should be in this thread:
OPENCORES.ORG
Open Hardware
OpenSPARC
The Wikipedia article on Open-Source Hardware, with many more links
This is about the umpteenth time we hear about this. Somehow, I can't believe anymore that putting these chips in passports was meant to increase security. The question is...what _was_ the purpose?
``A comment indicitive of someone who lives relatively close to the equator. For those of us who see a 6-12 hour difference in the number of daylight hours it can make a real difference.''
I don't see that. How does shifting the clock time by 1 hour offset 6-12 hours of difference in daylight?
I live at 52 degrees latitude, in a country that does DST, and I hate it. It's not just people who forget about the clock change and show up an hour late or early. It's also the confusion that ensues from clock time not being continuous. And there's no way out...you can record times so that they are continuous, but then people get confused because the recorded time doesn't match clock time.
Personally, I think DST is an abomination and should be abolished. And, while we're at it, let's think hard about time zones, too.
``(Actually, that's one of the things that pisses me off most about the party-based government systems: you can't vote for specific policies, you either pick the Liberal package, or the Labor package (Labour/Tory, Dem/GOP, whatever).''
s/party-based/two-party/
The problem here is that you only have two realistic choices. Any vote that isn't for a large party is likely lost. Some countries have a system of proportional representation. This allows you to vote for the party you like best, and the more people who do so, the more influence that party will have on policy. You don't have to pick the lesser of two evils to prevent the greater from coming to power.
I was actually under the impression that Australia had a multi-party system with proportional representation. Is this not the case?
While I haven't actually thought out a solution to the real problems related to child pornography, I feel the very least we can do is stop making the innocent and harmless suffer for it.
No solution is better than a "solution" that does more harm than good.
``Shai Agassi is a smart and charismatic man, but who can really say they're happy with the cell phone business model? Most consumers aren't, but the cellular networks are making quite a profit.''
I'm not complaining. I get to make and receive phone calls and text messages and access the Internet pretty much everywhere I go, for less money than my ADSL line costs.
DRM and open-source do not go together. They can't. If it is open-source, you can circumvent the restrictions. You can simply look at the code and change it so that it accepts whatever you want to do. Even if they depend on some information you get from a system that isn't under your control. You do it once, and then you can get at the content, and then you can decode the content, and then you can do whatever you want with it.
Conversely, if you cannot alter the software to disable the restrictions, it's not open source.
Having said that, I suppose it is possible to slap an open source license on your software, and still have users be legally disallowed from circumventing the DRM that is in your software.
Your points are all well taken, and I fully agree with your comments on HTML.
That leaves me with one question. Is Silverlight an open standard? Can I go and write my own implementation for my own platform and under my own license, and create a full implementation that can run any Silverlight app that has been coded to the standard, without having to fear lawsuits from Microsoft for infringing on their intellectual property?
When reading this, I couldn't help but wish _I_ got paid that much money. The figure I get from sloccount ($55K) seems high, but this is even higher than that! Anybody want to make me an offer?
It supports more hardware?
``Unfortunately, as you approach the limit, the performance must drop as you've now abstracted so far that your code becomes essentially a virtual machine on which your data runs.''
I don't see that. Not all abstraction makes things slower. In many cases, abstraction lets you write code at a higher level, while still compiling down to the code you would have written if working at a lower level.
> Journalling, by its very nature, implies turning every write into two writes.
First of all, that isn't necessarily true; I think Log-structured Filesystem) is one example of a filesystem that uses a journal, yet does not write everything twice. It also depends on how much consistency you want to maintain: many journalled filesystems have the option to journal structure, but not data. Secondly, extra writes don't necessarily cause a performance hit. It all depends on the usage patterns. If the writes can be performed when the disk would otherwise be idle, no performance is lost.
> > But one advantage of having a journal is that you can maintain consistency
> > even if you suffer a failure in the middle of a write.
> This is relevant and interesting if you are running a bank. It is completely uninteresting if you spend your day > writing text files and compiling them, like I do.
Right. Different jobs, different tools.
> > If you claim that compressed archives are more efficient for storing many small files, you had
> > better actually know at least one compressed archive format that actually is more efficient.
> > Otherwise, you would just be making an unfounded claim. Again, I ask you to back up your claims.
> What sort of foundation would you like to hear?
Anything that justifies your claim of compressed archives storing many small files more efficiently than any filesystem.
> I would consider it obvious for the simple reason that compressing a hundred files into an archive
> will always take less space than a hundred uncompressed files, no matter how efficiently they may
> be aggregated.
So you meant "space-efficient". I thought we were talking about time-efficiency. Ok, fair enough. But what if the filesystem compressed the files, as well?
> While you can compress the entire filesystem, that is usually not a good idea, because there is no
> generic way to determine which files should be compressed and which ones should not.
True, but the same goes for archive files, of course. Any metric that the archiver uses to determine which files should be compressed, the filesystem can use, too.
I think I see what you're getting at, though. The filesystem exposes a certain programming interface. Traditionally, this interface does not give applications a lot of control. For example, the application might know which files should be compressed, and which ones shouldn't, but the VFS does not typically allow this information to be communicated to the filesystem. A purpose-built storage system specific to the particular application could, of course, incorporate anything and everything that might be useful.
> First of all, I do not think that allowing the user to muck with application internal files with
> "standard tools" is a good idea.
Well, see, generalizations. In some cases, there is no significant gain to being able to use standard tools to manipulate some data. In that case, feel free to lump all that data together in a single file that only your application knows how to deal with. But that wasn't the case I was talking about. I was talking about the case where you have pieces of data that are meaningful to the user, like individual emails. I thought that was what you were talking about, as well. I'm certainly not proposing every byte of the email should be in its own file. But I can see where having a one-to-one correspondence between emails and files, and perhaps even email parts to files, or even email headers to files, would be useful. You seem to be arguing I shouldn't want to do this, because filesystems are bad at dealing with such small parts - I say, filesystems can be made to be good at this, let's do it! And _then_ we can decide if having a file per email header is a good idea or not.
> you aren't planning to tell all your users that they must use ReiserFS to use your ap
``Unfortunately, a lot of managers see "free" software and dive on that not understanding that they need people to maintain/support that.''
That's probably because they have people on staff who are supposed to maintain/support the software the company uses. Of course these people won't magically be able to support whatever others decide to throw at them, but that is the case regardless of whether the software is open-source or not. And the solution is the same as always: either get your people to learn the new software, or hire new people who already know.
``what does ' vendor support' really get you?''
Apparently, extra costs during normal operation, and extra costs in the event of failure, where you have to sit and wait for the support provider to diagnose the problem. And then maybe a free fix, if the provider decides that this is covered under their contract with you.
By contrast, without the vendor support, you have no extra cost during normal operation, and some of the people who would, in the vendor support scenario, be twiddling thumbs during downtime would instead be diagnosing and fixing the problem. And then you would have to pay for the fix.
There are a couple of scenarios where vendor support wins. For example, it could reduce your costs during normal operation, because your people don't need to be qualified to diagnose all possible problems - after all, that's what you have vendor support for. By the same token, if your people aren't as good at diagnosing problems as the vendor's people, vendor support may win in the event of problems, because they get diagnosed and fixed faster.
On the other hand, I prefer just having people who know the system well enough that they can anticipate and diagnose problems, and have spare parts on hand to deal with hardware failures. That way, I don't have to depend on a vendor for support, I don't have to pay the vendor for it, and I don't have to wait for the vendor to provide the support.