However, the EFF is not amused, stating that the chip will be used for DRM, and could even limit which software the owner installs on his cell phone.
Newsflash: Phones already have DRM, it's a lot harder for the average person to bypass than a computer, and phones already limit what applications can be installed, or what they can do.
If the voters of Podunk want to run a library that distributes translations of the Canterbury Tales in Swedish, that's their right.
This might shock you, but where I live this have already started to happen. The public libraries are spreading their filthy swedish propaganda; almost all the books are in swedish now. And there's nothing the government can do to stop it. That is, without the Patriot Act. So support the Patriot Act and free us from the swedish menace!
...Hm. Oh wait. I live in Sweden. Nevermind...
Re:Still Logging In? The System Isn't Finished.
on
Weighing the Internet
·
· Score: 1
Addendum: I haven't run Linux since 2001 and was convinced that by now someone had rewritten those wretched scripts to be a bit more streamlined. Obviously I was wrong. After having looked at their current state, yes they could probably gain a bit from parallelization but I think that's the wrong turn to take since they would gain far more from some simple optimization.
Re:Still Logging In? The System Isn't Finished.
on
Weighing the Internet
·
· Score: 1
Hehe. Good point. But I think you'd gain more from optimizing the scripts than just parallelizing them.
As I've said before, besides from those sleep the slowness comes from IO. Any CPU gain you get by parallelizing will be lost due to the fact you now need another bit of code to check finished process and keep a track of depenedencies.
Re:Still Logging In? The System Isn't Finished.
on
Weighing the Internet
·
· Score: 1
Not until you take a basic course in computer I/O.
Suprise suprise. I have. And I've written kernel patches. And I've done my own Linux system from source (no, no easypeasy Gentoo). And I've written my own OS, which admittely did little more than Linus first teletype program.
But as I said in reply to some other comment, the gains of parallelizing the current script architecture isn't very great. The amount of cpu work most boot-up scripts do is insignificant to the amount of IO they do. So as long as you've got your one cpu, one system disk system they'll be spending 95% of their time waiting for IO which no parallelizing will get you out of.
Re:Still Logging In? The System Isn't Finished.
on
Weighing the Internet
·
· Score: 1
Boot-up processes is most often almost completly IO which is why I said "one system disk" too. The gain in parallelizing them is often negligible small. I think a far better approach would be by bypassing the current boot-up script architecture completly and load only bare minimum services to get the desktop up and then load the rest once that has been accomplished.
Re:Still Logging In? The System Isn't Finished.
on
Weighing the Internet
·
· Score: 1
However, if you have proper service dependency information (like LSB-based distros should all have, and Gentoo has for sure), instead of just boot order numbers (/etc/rc2.d/SNNsomeservice), you can parallelize a lot of the boot process.
Please explain to me how you speed up the boot process by parallelizing something on a one cpu - one system disk machine.
Look at the shoot-out with only tests that are all available for C, C++ and O'Caml are included and weighted for both CPU and Memory. It paints quite another picture.
Hm. Slashcode messed with the URL. Use good old copy and paste:
http://shootout.alioth.debian.org/great/benchmar k. php?test=all&lang=all&sort=fullcpu&xfullcpu=1&xmem =1&xloc=0&ackermann=1&wc=3&echo=5&fannkuch=0&fasta =0&fibo=1&harmonic=0&heapsort=4&knucleotide=0&mand elbrot=0&matrix=3&nbody=0&nsieve=0&nsievebits=0&ob jinst=5&methcall=5&pidigits=0&random=3®exmatch= 0&revcomp=0&reversefile=4&spellcheck=0&hello=0&mom ents=0&sumcol=0&takfp=1&tcpecho=0&tcprequest=0&tcp stream=0&process=0&message=0&wordfreq=5
Look at the shoot-out with only tests that are all available for C, C++ and O'Caml are included and weighted for both CPU and Memory. It paints quite another picture.
Sure, and obviously it's rarely worth the trauma of the latter. (Especially when change has become as traumatic as it appears it has at Microsoft.) But where would Microsoft be now if they hadn't made the switch?
I would say there's three very important things to note here:
Microsoft did not throw away the old codebase. Instead they continued to develop it for over 10 years in parallel with the new one. Which leads us into
You (as in virtually any other company) don't have the kind of money that two full OS-teams working for 10 years cost.
Microsoft is incredibly good at maintaining "code-memory". They move all that relevant code into whatever new thing they do. The old classic SimCity bug is a shining example of this.
Then I guess most major software companies have been moronic at some point or other. (OK, I'll grant that that's probably true on other grounds.) Take even Microsoft as an example - what legacy of the original PIA exists in NTFS? It was essentially rewritten at one point when it was decided the original wasn't maintainable.
I don't think anyone's arguing that rewriting modules and parts of the code can't and shouldn't be done. What we're talking about is taking your whole foundation and throwing it out the window i.e Netscape's browser or Microsofts Win32 API. Not saying that most companies haven't been moronic at one point or other. But there's a big difference between rewriting parts and rewriting your complete software base. If nothing ever was rewritten we wouldn't be making much progress now would we?:)
Universities and other places picked up Unix because it was tractable and ran on affordable hardware.
I still don't see your point. Your saying that it was better to write code for a platform people could afford. Wow. Considered going into marketing? What this has to do with starting a new codebase, I don't understand. Their choice to "abandon" Multics wasn't voluntarily and the fact they got a cheap platform for UNIX was because they didn't get any funding.
. Throughout 1969 we (mainly Ossanna, Thompson, Ritchie) lobbied intensively for the purchase of a medium-scale machine for which we promised to write an operating system; the machines we suggested were the DEC PDP-10 and the SDS (later Xerox) Sigma 7. The effort was frustrating, because our proposals were never clearly and finally turned down, but yet were certainly never accepted.
-The Evolution of the Unix Time-sharing System, Dennis M. Ritchie, 1979
A dogmatic assertion that rewrite is never indicated is just as wrong as one that it's always a good idea.
I'd qualify the lone assembler programmer on the project dying in a car accident as "extreme circumstances":). But hey, I don't know about you, perhaps that happens to your projects frequently. The only thing that's always true is that there's nothing that's always true. I mean, yes, there is code that's beyond saving. But in a professional company developing software for a living? Then something is fundamentally wrong and no rewriting will help you. In the case of a normal company, developing shrinkwrap software, abandoning a codebase is moronic.
And yet it was released, during the long period that AT&T couldn't quite figure out what to do with Unix. But for all of that, it seems to have left little legacy today, beyond those features adopted by Unix.
I honestly don't see your point here? An ill-backed system doesn't leave a legacy. Gee whiz, I'm suprised. The point is that if they hadn't rewrote it from scratch (and as we should note, they didn't want to either) we might have ended up with a mature "UNIX" much quicker. Also, it was other days back then. We're not talking about programs that would be deployed on a million different configurations in a thousand languages and cultures. Instead they were usually targeted for a very specific machine. This changes the whole concept quite a bit.
Or perhaps never at all. A large body of pre-existing code can be a disadvantage, if it is not amenable to adaptation for new purposes, and is not organized in a way to encourage new contributions. This is obviously true for open-source projects, but applies to proprietary software as well.
The thing, that a lot of people seem to fail to grasp here, is that Netscape (the company) died because of this decision. They disappeared from "the scene" and got downsized and bought. Now they're just a joke. As I've said, open source/hobby projects can afford to waste 5 years rewriting from scratch because they won't lose their income while they do it. A company doesn't have that privilege.
And if your code is such as mess that it doesn't encourage contributions: refactor and clean up, don't throw the baby out with the bath water.
I got it to around 35 lines of code for opening the default mixer device, initializing, setting the mute value and uninitializing. And that's checking for errors too. Yes, there were big structs, which isn't unexpected. This is an OS-level API. If people want to have a SetMute(true); then use an audio-library. That's what they're there for.
As an example, was Dennis Ritchie wrong to toss away all that mass of Multics code and write Unix from scratch? Somehow, Multics didn't seem to benefit in the long run from its "head start."
Multics took a hard hit, when early on BTL dropped out of the project, which it never recovered from. And with that, the project lost Ken Thompson and Dennis Ritchie as developers. Since those two didn't have the possibility to reuse old code from the Multics project and had (after many twists and turns) a new system to develop on, they had no choice than to start from scratch. Even though they did this, they imported many ideas and experiences from Multics. In fact, had Bell not pulled out it's very possible we would have a Linics today.
Or, in the case Joel harps on, was it really the wrong decision for the Mozilla crew to toss the old Netscape code and rewrite Gecko from scratch? Perhaps at the time Joel wrote his article it wasn't clear that they had taken the correct approach, but I'd say events have shown the Mozilla team's decision was correct.
Or we would have had a Firefox 3 years ago. You should note that Firefox is not a company effort, and can afford the time a complete rewrite entails and even then it's a waste. Perhaps we could by now have Firefox 3.0 with a more mature and robust codebase and with a far larger marketshare. IE would never have been given that big empty window alone on the scene which projected it to monopoly.
I'm not saying the Win32 API is a beautiful flower of perfection, but it's far from braindead. I have to wonder what you did in those 120 lines considering you can write far more advanced Win32 programs in far less:), but sure, Win32 takes some lines to properly initialize.
However, the fact that you don't see why this is needed doesn't mean it isn't needed. Half of those lines and their cryptic arguments is to ensure that some bug doesn't show up. Or that some programmer in deepest Africa can use his native language consisting of tounge-clicks.
Also, I don't quite understand your aversion against the event system? I myself prefer to get messages, but if you want callbacks you can easily set them up in your event loop. Sending the event on to the default handler is seldom more than one line of code, so if you think that's a bother perhaps you should be doing something else?
To return to the original argument,.NET does simplify things compared to the old Win32 API. Perhaps a little to much. But as long as things work it's very nice to work in. I've done virtually as much "real" work in.NET as I have in the old API which perhaps distorts my perception. And even more work in QT, GTK and Motif/Xlib.
Ah boy, I wouldn't want to hire you. Microsoft sits on a treasure chest, namely 10 years of bugfixed, known-to-be-working code. It contains every little obscure bugged that grandma Uxbuklu in outer Mongolia have ever encountered. And you want them to throw that away? That sounds great! If you're a Linux developer that is.
I would recommend you read what Joel has to say, since he say it so much better than I have time to do.
Once again someone misses the point. The "Killer Feature" isn't the templates. The killer feature is templates coupled with the editor & kitchen-sink that is Dreamweaver. By themselves they're nothing special.
It means..*gasp* normal. You know english have a lot of words from nordic languages right?:) Like house, ballast, husband, et cetera. Some 1000 years ago Brits and Norsemen could talk and understand eachother. So if something looks like the same word you can at least guess that it's the same word. Except for 'kiss'. That means pee.
now in some countries the 2-2.5G _is_ happening already.
Eh, all my friends have 3G mobile phones, with free video calls within their net and for a small fee to other nets. They've also got several tv-channels (such as news, music, etc) to choose from for a flat fee, not to mention full internet connectivity. But then I live in a civilized country like Sweden.
Slashdot Mirror
Many newer phones don't allow for example file-system interaction from unsigned applications.
Newsflash: Phones already have DRM, it's a lot harder for the average person to bypass than a computer, and phones already limit what applications can be installed, or what they can do.
No. Sweden. Yes, quite a lot of them.
If the voters of Podunk want to run a library that distributes translations of the Canterbury Tales in Swedish, that's their right.
...Hm. Oh wait. I live in Sweden. Nevermind...
This might shock you, but where I live this have already started to happen. The public libraries are spreading their filthy swedish propaganda; almost all the books are in swedish now. And there's nothing the government can do to stop it. That is, without the Patriot Act. So support the Patriot Act and free us from the swedish menace!
Addendum: I haven't run Linux since 2001 and was convinced that by now someone had rewritten those wretched scripts to be a bit more streamlined. Obviously I was wrong. After having looked at their current state, yes they could probably gain a bit from parallelization but I think that's the wrong turn to take since they would gain far more from some simple optimization.
Hehe. Good point. But I think you'd gain more from optimizing the scripts than just parallelizing them.
As I've said before, besides from those sleep the slowness comes from IO. Any CPU gain you get by parallelizing will be lost due to the fact you now need another bit of code to check finished process and keep a track of depenedencies.
Not until you take a basic course in computer I/O.
Suprise suprise. I have. And I've written kernel patches. And I've done my own Linux system from source (no, no easypeasy Gentoo). And I've written my own OS, which admittely did little more than Linus first teletype program.
But as I said in reply to some other comment, the gains of parallelizing the current script architecture isn't very great. The amount of cpu work most boot-up scripts do is insignificant to the amount of IO they do. So as long as you've got your one cpu, one system disk system they'll be spending 95% of their time waiting for IO which no parallelizing will get you out of.
Boot-up processes is most often almost completly IO which is why I said "one system disk" too. The gain in parallelizing them is often negligible small. I think a far better approach would be by bypassing the current boot-up script architecture completly and load only bare minimum services to get the desktop up and then load the rest once that has been accomplished.
However, if you have proper service dependency information (like LSB-based distros should all have, and Gentoo has for sure), instead of just boot order numbers (/etc/rc2.d/SNNsomeservice), you can parallelize a lot of the boot process.
Please explain to me how you speed up the boot process by parallelizing something on a one cpu - one system disk machine.
Seriously, a (support) technician is like the plumber. He's only called when something is broken. How much respect do you show your plumber?
Look at the shoot-out with only tests that are all available for C, C++ and O'Caml are included and weighted for both CPU and Memory. It paints quite another picture.
r k. php?test=all&lang=all&sort=fullcpu&xfullcpu=1&xmem =1&xloc=0&ackermann=1&wc=3&echo=5&fannkuch=0&fasta =0&fibo=1&harmonic=0&heapsort=4&knucleotide=0&mand elbrot=0&matrix=3&nbody=0&nsieve=0&nsievebits=0&ob jinst=5&methcall=5&pidigits=0&random=3®exmatch= 0&revcomp=0&reversefile=4&spellcheck=0&hello=0&mom ents=0&sumcol=0&takfp=1&tcpecho=0&tcprequest=0&tcp stream=0&process=0&message=0&wordfreq=5
Hm. Slashcode messed with the URL. Use good old copy and paste:
http://shootout.alioth.debian.org/great/benchma
Look at the shoot-out with only tests that are all available for C, C++ and O'Caml are included and weighted for both CPU and Memory. It paints quite another picture.
I would say there's three very important things to note here:
Then I guess most major software companies have been moronic at some point or other. (OK, I'll grant that that's probably true on other grounds.) Take even Microsoft as an example - what legacy of the original PIA exists in NTFS? It was essentially rewritten at one point when it was decided the original wasn't maintainable.
:)
I don't think anyone's arguing that rewriting modules and parts of the code can't and shouldn't be done. What we're talking about is taking your whole foundation and throwing it out the window i.e Netscape's browser or Microsofts Win32 API. Not saying that most companies haven't been moronic at one point or other. But there's a big difference between rewriting parts and rewriting your complete software base. If nothing ever was rewritten we wouldn't be making much progress now would we?
I still don't see your point. Your saying that it was better to write code for a platform people could afford. Wow. Considered going into marketing? What this has to do with starting a new codebase, I don't understand. Their choice to "abandon" Multics wasn't voluntarily and the fact they got a cheap platform for UNIX was because they didn't get any funding.
A dogmatic assertion that rewrite is never indicated is just as wrong as one that it's always a good idea.
I'd qualify the lone assembler programmer on the project dying in a car accident as "extreme circumstances"
And yet it was released, during the long period that AT&T couldn't quite figure out what to do with Unix. But for all of that, it seems to have left little legacy today, beyond those features adopted by Unix.
I honestly don't see your point here? An ill-backed system doesn't leave a legacy. Gee whiz, I'm suprised. The point is that if they hadn't rewrote it from scratch (and as we should note, they didn't want to either) we might have ended up with a mature "UNIX" much quicker. Also, it was other days back then. We're not talking about programs that would be deployed on a million different configurations in a thousand languages and cultures. Instead they were usually targeted for a very specific machine. This changes the whole concept quite a bit.
Or perhaps never at all. A large body of pre-existing code can be a disadvantage, if it is not amenable to adaptation for new purposes, and is not organized in a way to encourage new contributions. This is obviously true for open-source projects, but applies to proprietary software as well.
The thing, that a lot of people seem to fail to grasp here, is that Netscape (the company) died because of this decision. They disappeared from "the scene" and got downsized and bought. Now they're just a joke. As I've said, open source/hobby projects can afford to waste 5 years rewriting from scratch because they won't lose their income while they do it. A company doesn't have that privilege.
And if your code is such as mess that it doesn't encourage contributions: refactor and clean up, don't throw the baby out with the bath water.
I got it to around 35 lines of code for opening the default mixer device, initializing, setting the mute value and uninitializing. And that's checking for errors too. Yes, there were big structs, which isn't unexpected. This is an OS-level API. If people want to have a SetMute(true); then use an audio-library. That's what they're there for.
As an example, was Dennis Ritchie wrong to toss away all that mass of Multics code and write Unix from scratch? Somehow, Multics didn't seem to benefit in the long run from its "head start."
Multics took a hard hit, when early on BTL dropped out of the project, which it never recovered from. And with that, the project lost Ken Thompson and Dennis Ritchie as developers. Since those two didn't have the possibility to reuse old code from the Multics project and had (after many twists and turns) a new system to develop on, they had no choice than to start from scratch. Even though they did this, they imported many ideas and experiences from Multics. In fact, had Bell not pulled out it's very possible we would have a Linics today.
Or, in the case Joel harps on, was it really the wrong decision for the Mozilla crew to toss the old Netscape code and rewrite Gecko from scratch? Perhaps at the time Joel wrote his article it wasn't clear that they had taken the correct approach, but I'd say events have shown the Mozilla team's decision was correct.
Or we would have had a Firefox 3 years ago. You should note that Firefox is not a company effort, and can afford the time a complete rewrite entails and even then it's a waste. Perhaps we could by now have Firefox 3.0 with a more mature and robust codebase and with a far larger marketshare. IE would never have been given that big empty window alone on the scene which projected it to monopoly.
I'm not saying the Win32 API is a beautiful flower of perfection, but it's far from braindead. I have to wonder what you did in those 120 lines considering you can write far more advanced Win32 programs in far less :), but sure, Win32 takes some lines to properly initialize.
.NET does simplify things compared to the old Win32 API. Perhaps a little to much. But as long as things work it's very nice to work in. I've done virtually as much "real" work in .NET as I have in the old API which perhaps distorts my perception. And even more work in QT, GTK and Motif/Xlib.
However, the fact that you don't see why this is needed doesn't mean it isn't needed. Half of those lines and their cryptic arguments is to ensure that some bug doesn't show up. Or that some programmer in deepest Africa can use his native language consisting of tounge-clicks.
Also, I don't quite understand your aversion against the event system? I myself prefer to get messages, but if you want callbacks you can easily set them up in your event loop. Sending the event on to the default handler is seldom more than one line of code, so if you think that's a bother perhaps you should be doing something else?
To return to the original argument,
Ah boy, I wouldn't want to hire you. Microsoft sits on a treasure chest, namely 10 years of bugfixed, known-to-be-working code. It contains every little obscure bugged that grandma Uxbuklu in outer Mongolia have ever encountered. And you want them to throw that away? That sounds great! If you're a Linux developer that is.
I would recommend you read what Joel has to say, since he say it so much better than I have time to do.
11. What is the official eXeem website? Return
the eXeem website is located here, but the official eXeem client does contain spyware!
Once again someone misses the point. The "Killer Feature" isn't the templates. The killer feature is templates coupled with the editor & kitchen-sink that is Dreamweaver. By themselves they're nothing special.
It means..*gasp* normal. You know english have a lot of words from nordic languages right? :) Like house, ballast, husband, et cetera. Some 1000 years ago Brits and Norsemen could talk and understand eachother. So if something looks like the same word you can at least guess that it's the same word. Except for 'kiss'. That means pee.
A witch of the northern gods? Hahaha. Ah, I love people who take up religions and ideas they have no clue about. *shaking my head*
Sejd är inget man brukar som en normal följare av fornsed och saker som kallas 'häxa' brukar vara av ondo.
Did you understand that? Didn't think so. Your grasp of Swedish seem to be on par with your grasp on the beliefs you claim to adher to.
Eh, all my friends have 3G mobile phones, with free video calls within their net and for a small fee to other nets. They've also got several tv-channels (such as news, music, etc) to choose from for a flat fee, not to mention full internet connectivity. But then I live in a civilized country like Sweden.