I think the choices Steve is making are very clear: the choice is: MacOS or iPhoneOS. Light or Dark. It is clear he's made the choice for an era of darkness... sadly enough it will only make the Mac platform less popular amongst techies who where the primary adopters after MacOS X.
And the economics of a closed fully controlled platform, have been in Steve's dreams since the seventies. Luckily we all know it will ultimately utterly fail, as so many closed platforms in the past. It will take a while. It might be hard for hackers such as us, but we will prevail! Sad to see Apple go down like this, was a big fan, contributor, promotor, book writer, journalist and so on for years.
I am really disappointed in Steve. At least Google tries a little bit to 'do no evil', Steve makes beautiful things, but with a very bitter taste!
Facebook group: iPad is an attack on our freedom
We use Fedora, RHEL, Ubuntu and OpenSuSE all the time for our Linux courses to IT Experts.
The new users only like Ubuntu and RHEL 'stability' doesn't match with their stupid backporting because they just like a lower version number. In the end it's very arrogant of Red Hat to pretend to know better than the LKML and they produce a less stable and less tested end result.
Let's hope Ubuntu will keep up their good work!
Jasper.
For all platforms they found that 20% of the machines with errors make up more than 90% of all observed errors on that platform.
So essentially, they are saying that only 8% of DIMMSs reported errors, 90% of which were on 20% of the machines that had errors, mostly because of motherboard issues... yet DIMMs are less reliable than previously thought.
I would imagine that if you removed all of the bad motherboards, power supplies, environmental, and other issues... that DIMMs are actually more reliable than I previously thought, not less!
I agree.
Most of the 'Uncorrectable Error'-events they notice are propably more power-supply related than RAM related events.
At least that is our experience with 'bad systems' who go down periodically without no apparent reason; replacing the power supply mostly does the trick. The idea that must be a RAM issue is often a wrong one; and it has had so many customers struggling with doing weeks of memtesting, suspecting the innocent linux kernel or making up even stranger things; while the conclusion of such event is mostly: power supply.
It was so with all VA Linux Systems machines in the past (we did the European support for those), and still actual with our experiences in customer datacenters.
Yet Google has a special power supply infrastructure... ... do they have a problem there, or am I missing the point completely somewhere?
Which would be correct if make was a purely CPU bound process.
The point I'm making here is that it isn't. Because the processes have to wait for I/O anyhow (latest kernel source tree is 400mb before make and 650mb after, so involves not some little amount of I/O).
So any DECENT scheduler should be able to deal with the n+1 and/or n+2end make processes as well while the n first processes are in I/O wait state.
On very slow CPU's compiling something might seem to be CPU bound, but with modern hardware it isn't anymore. Take compiling the kernel as an example.
In his FAQ, he uses make -j as an example for CPU bound processes. In modern hardware it's more of an I/O bound process than CPU bound.
This is also why you will still see a lot of CPU idle time on make -j 2 on a dual core with a 'normal' scheduler. And that's also what it should be.
If you create a scheduler who has in the same situation less idle time, it only means that you have created a less efficient one... and one shouldn't celebrate a better scheduler!:)
Test cpu intensive load with CPU bound processes, I/O bound with I/O bound processes. But if a scheduler designer thinks make is a CPU bound process, should we even take time to look at his code?
Who cares about his scheduler focus, while performance bottlenecks and especially his 'examples' are mostly I/O related.
If a make -j 4 makes your quadcore machine choke, it's indeed a BRAINFUCKED coder who made it... CPU cycles should be plentifull available in between the I/O operations.
Still wonder why he's able to get that much media attention...... luckily nobody on LKML cares neither...
They claim to have patented this method... So if you search for 'blacklight' in the US Patent Office Database you get this.
As happy as I would be to believe in ultimate and clean renewable energy, it turns out Blacklight Power Inc. is more interested in things as 'rear view mirrors' and ' Liquid crystal display devices' than quantum mechanics.
Well I think the link between MS and the BSA has always been very strong. Financially the BSA is by far the most funded by Microsoft (Adobe is a distant far second if I recall correctly).
As Microsoft's biggest 3 competitors are: 1) itself and her older versions (seriously, MS looks at this in that way)
2) piracy, hence their involvement in creating the BSA and funding it
3) Linux (which we will not discuss here:)
On another note they also use the BSA in Europe to lobby for software patents and to say that MS's XML is an 'open document format enough' (at least in Belgium, out of personal experience).
I guess it must be like that out/in own pocket operation of Mr. Gates with his 'Foundation' helping poor children in the third world by buying MS licenses for them...
Section 8 is intended to be used to help copyright holders (people who wrote the GPL program) when certain technologies are prohibited from full international distribution due to patent restrictions in certain parts of the world.
This means: if you don't have a license for a software patent valid in the US only, then the GPL software can still be distributed in the rest of the world.
My first remark is simple: this MS license DOES NOT GIVE YOU THE RIGHT TO MAKE GPL SOFTWARE TO USE THEIR PATENT. And, yes, thanks to the GPL, people who live in other parts of the world than the US, simply don't need to have a patent license and can happily distribute their software with geographic limitations.
Nope, it explicitly says the GPL needs to be provided. Section 8 can add geographic limitations (as mentioned in another comment), but adding the requirement that a notice has to be included in the program to thank Microsoft or whomever is of course incompatible with the GPL!
Just as it's - for example - incompatible to add the requirement that the software can not be used for atomic weapon deployement.
I would vote to append such a statement to the GPL, but Richard Stallman (while I'm sure he's against the usage of real weapons of mass destruction), choose not to add such a possibility to the GPL as it would - at the end of the day - require you to send a greeting card, donate 1$ to charity, plant a flower, see 3255 notices (and so on) before you could use your entire GPL software distribution.
In the old days...
I'm talking pre-linux-1.0 now...
The BSD folks tend to say: nobody will like the GPL because no business will accept it.
Turns out you were wrong: We live now in 2003 and most of the OpenSource software written is GPLed, and we love it.
I don't want to say the BSD license is evil, not at all (while BSD supporters are often less friendly wrt GPL)! Yet the GPL is a better guarantee for our freedom as technological people than the BSD license.
The evolution since the 90s till now has also proven that the GPL license is a more succesfull software license, aside from bringing more freedom to the general public.
Commercially speaking, the BSD license can sometimes be more interesting, however... not in all cases.
The way I see 'giving back' is one in which the freedom of the software is guaranteed, so I don't see any problem there.
Microsoft has just tried another time to:
1) Have an argument in their discussion with government that their license is 'open enough'.
2) Work contradictory to anything remotely touching it's only cash cow: MS Office.
If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
This clearly DOES NOT state that you can append restrictions on the usage of your software.
It's exactly the same reason for which everybody moved from XFree86 to X.org: the obligation to put on it the notice.
It might seem to be of little importance,... just a notice, but it's pandora's box!
So, this brings up the real question: are you an MS fud monkey?
This means a WISP in a box for everyone - and LinSpot handles the roaming between all linspots and fills your PayPal account while you sleep (and while others roam).
I guess it will take the LinSpot crew a couple of weeks to iron the bugs out and release this for your enjoyement.
Pulverinnovations sells this already - without WEP
on
WiFi Phone Announced
·
· Score: 0, Redundant
They don't do WEP or WPA encryption, and you have to wait about 6 weeks before you get your order, but it works nicely, also behind firewalls... Probably WEP is not such a idea good for latency as well...
WiFi surely is interesting:)
But I guess I'm biased.
... they should have left an option open for people finding holes in the ACTUAL implementation...
Now only mathematicians stand a chance - go, go, go, you few good number theoretisists not employed by the NSA!
=-= insert favorite conspiricy theory here =-=
Should have upgraded my RH 7.3 box long time ago to something newer... but the Fedora way just didn't seem right to me.
Installing Debian from boot CDs and such didn't sounded so appealing to me,... I guess the OpenSource gods are with me today!
Thanks!
Using an external source to find out the port numbers is the way it can be implemented the best.
How this is done for SIP-based VoIP - THE STANDARD FOR VoIP. Can be read on this interesting document (page 13 and on are the parts you want to look at).
Basically it works as you described. The third party is called a 'NAT proxy', which forwards the necessary external port numbers and communicate that information with the clients during the communication initiation phase. But it doesn't work for 'Symmetrical NAT'.
For Symmetrical NAT, a so-called 'NAT proxy' is being used to forward the
Price comparisation:
- comparisation of artificially low memory systems as Apples prices are where Apple makes the most on. On the one hand claiming 'we don't want to build ourselves as Apples can't be build, and then going to another store to add memory, just isn't fair when comparing prices.
- Boot-testing the Mac for performance difference with other the HD is a good thing, but the test in the other direction (booting the PC with the other HD might reveal that the bottleneck is in the other direction).
- MacOS X is certainly better in 64bit environments than not wanting to run beta software on a system bought for performance.
- The problem with the Mac is also that the graphics subsystem is already dated. The release cycle of Macs is just too long. When they're first released they -arguably- beat most of the fastest PC's. But the next version is only released at quickest 6 months later, if you compare at that time with latest hardware. Macs just can cope up.
- I also assume that near the end of the cycle, Apple's profit margins are incredible high. It's a very good marketing tactic to keep hardware and software tied to each other, keeping it all under control.
- As I'm typing this on my top-equipped 12" PowerBook, I must admit that MacOS X is a good OS and the hardware is very good (this laptop was cheaper than any comparable hardware at the time I ordered it - not any more at the time when it got delivered)
- And as a rule of thumb, I always say it's better to buy a less expensive system and upgrade it quicker than to go for the fastest and be stuck with it for an extra year.
- Macs also have a better second hand value, and that shouldn't be forgotten when taking the price into account.
- But most performance comparisations clearly SUCK because they tend to be optimised for a certain system (because of lack of knowledge of the party), or highly dependent on release schedules of involved hardware or software.
Maybe my responce is a bit late for the slashdot reading people to notice, but I write it for you Bruce.
Gnome is a good choice when you have to choose only one.
KDE is with qt an interesting option when you want to create a simply ported multiplatform application with GUI. But if you look at the currently available important (from target population market share point) applications... You have to conclude that at this present moment most important Windows applications ARE NOT developed with qt and if they want to port to Linux, they have to choose a new GUI toolkit for their new 'Linux porting department' anyway.
They have to choose for an entirely new GUI toolkit anyway!
Would they choose for a crammy, not as widely used qt-toolkit with some commercial ties (to trolltech in one way or another - at least that's the perception). Or should they choose for an entirely free based, completely new GUI toolkit and different looking from Windows where they wanted to move from away?
The answer is clear. And more importantly the result: all the new 'important' applications are written in GTK and not in QT. The KDE people have written perfectly good QT equivalents. Congratulations. But if you have to choose only one...
It's only the GUI toolkit, not more...
It's more efficient to target your programming differences into other fields! If you look at it from an efficienty point of view!
So, ideally: the qt-designers should move forward to integrate the gtk toolkit into their own. Integration should be the ultimate proof that the OpenSource model works into a level which matches beyond the absurdity level of corporate software development.
Probably I'm dreaming. And probably I used too much drugs...
But what would happen if the KDE-core developer mailinglist and the core GLib mailinglist would suddenly merge into a new LinLib mailinglist....
Its possible that one of the other big propriatory software companies, like Adobe, could be behind it. We may never know.
So lets ask Google:
- "Royal Bank of Canada Microsoft": 7,990 hits
- "R.. B.. C.. Compaq": 1,690 hits
- "R.. B.. C.. IBM": 7,960 hits
-... Adobe: 1,910 hits
-... The Canopy Group": 12 hits
-... Bill Gates": 377 hits
Hey, found a link there...:
- In July this year, the new appointed Chief Privacy Strategist Peter Cullen for Microsoft came from the Royal Bank of Canada.
-... Paul Allen: 35 hits
But according to an intersting post on OSNews by Roberto here, "Baystar Capital" and not the Royal Bank should be the connection... but hits there surely have been influenced already with rumor-news...
Slashdot Mirror
And the economics of a closed fully controlled platform, have been in Steve's dreams since the seventies. Luckily we all know it will ultimately utterly fail, as so many closed platforms in the past. It will take a while. It might be hard for hackers such as us, but we will prevail! Sad to see Apple go down like this, was a big fan, contributor, promotor, book writer, journalist and so on for years.
I am really disappointed in Steve. At least Google tries a little bit to 'do no evil', Steve makes beautiful things, but with a very bitter taste! Facebook group: iPad is an attack on our freedom
We use Fedora, RHEL, Ubuntu and OpenSuSE all the time for our Linux courses to IT Experts.
The new users only like Ubuntu and RHEL 'stability' doesn't match with their stupid backporting because they just like a lower version number. In the end it's very arrogant of Red Hat to pretend to know better than the LKML and they produce a less stable and less tested end result.
Let's hope Ubuntu will keep up their good work!
Jasper.
For all platforms they found that 20% of the machines with errors make up more than 90% of all observed errors on that platform.
So essentially, they are saying that only 8% of DIMMSs reported errors, 90% of which were on 20% of the machines that had errors, mostly because of motherboard issues... yet DIMMs are less reliable than previously thought.
I would imagine that if you removed all of the bad motherboards, power supplies, environmental, and other issues... that DIMMs are actually more reliable than I previously thought, not less!
I agree.
Most of the 'Uncorrectable Error'-events they notice are propably more power-supply related than RAM related events.
At least that is our experience with 'bad systems' who go down periodically without no apparent reason; replacing the power supply mostly does the trick. The idea that must be a RAM issue is often a wrong one; and it has had so many customers struggling with doing weeks of memtesting, suspecting the innocent linux kernel or making up even stranger things; while the conclusion of such event is mostly: power supply.
It was so with all VA Linux Systems machines in the past (we did the European support for those), and still actual with our experiences in customer datacenters.
Yet Google has a special power supply infrastructure...
... do they have a problem there, or am I missing the point completely somewhere?
The point I'm making here is that it isn't. Because the processes have to wait for I/O anyhow (latest kernel source tree is 400mb before make and 650mb after, so involves not some little amount of I/O).
So any DECENT scheduler should be able to deal with the n+1 and/or n+2end make processes as well while the n first processes are in I/O wait state.
During testing (on the Windows platform!) I guess it's safe to assume that everything was handled by filesystem cache.
The comparisation with compiling the kernel on Linux on a machine with not too much RAM doesn't stand.
And the fact that BFS isn't even able to properly schedule n+1 lightly-cpu-bound processes certainly doesn't talk in it's favor.
But it's true; I haven't tested the code yet, and miracles could exist, but his analysis isn't confidence inspiring - to say the least.
On very slow CPU's compiling something might seem to be CPU bound, but with modern hardware it isn't anymore. Take compiling the kernel as an example. In his FAQ, he uses make -j as an example for CPU bound processes. In modern hardware it's more of an I/O bound process than CPU bound. This is also why you will still see a lot of CPU idle time on make -j 2 on a dual core with a 'normal' scheduler. And that's also what it should be. If you create a scheduler who has in the same situation less idle time, it only means that you have created a less efficient one... and one shouldn't celebrate a better scheduler! :)
Test cpu intensive load with CPU bound processes, I/O bound with I/O bound processes. But if a scheduler designer thinks make is a CPU bound process, should we even take time to look at his code?
Who cares about his scheduler focus, while performance bottlenecks and especially his 'examples' are mostly I/O related. If a make -j 4 makes your quadcore machine choke, it's indeed a BRAINFUCKED coder who made it... CPU cycles should be plentifull available in between the I/O operations. Still wonder why he's able to get that much media attention... ... luckily nobody on LKML cares neither...
They claim to have patented this method... So if you search for 'blacklight' in the US Patent Office Database you get this.
As happy as I would be to believe in ultimate and clean renewable energy, it turns out Blacklight Power Inc. is more interested in things as 'rear view mirrors' and ' Liquid crystal display devices' than quantum mechanics.
Financially the BSA is by far the most funded by Microsoft (Adobe is a distant far second if I recall correctly).
As Microsoft's biggest 3 competitors are:
1) itself and her older versions (seriously, MS looks at this in that way)
2) piracy, hence their involvement in creating the BSA and funding it
3) Linux (which we will not discuss here
On another note they also use the BSA in Europe to lobby for software patents and to say that MS's XML is an 'open document format enough' (at least in Belgium, out of personal experience).
I guess it must be like that out/in own pocket operation of Mr. Gates with his 'Foundation' helping poor children in the third world by buying MS licenses for them...
GLP: 19786 projects
LGPL: 2446 projects
BSD (old): 1456 projects
BSD (new): 787 projects
If you want to find it yourself: go to freshmeat.net, click browse, click license, click osi-approved:
And there you are!
This means: if you don't have a license for a software patent valid in the US only, then the GPL software can still be distributed in the rest of the world.
My first remark is simple: this MS license DOES NOT GIVE YOU THE RIGHT TO MAKE GPL SOFTWARE TO USE THEIR PATENT. And, yes, thanks to the GPL, people who live in other parts of the world than the US, simply don't need to have a patent license and can happily distribute their software with geographic limitations.
Just as it's - for example - incompatible to add the requirement that the software can not be used for atomic weapon deployement.
I would vote to append such a statement to the GPL, but Richard Stallman (while I'm sure he's against the usage of real weapons of mass destruction), choose not to add such a possibility to the GPL as it would - at the end of the day - require you to send a greeting card, donate 1$ to charity, plant a flower, see 3255 notices (and so on) before you could use your entire GPL software distribution.
So the short answer to your question is: no.
I'm talking pre-linux-1.0 now...
The BSD folks tend to say: nobody will like the GPL because no business will accept it.
Turns out you were wrong: We live now in 2003 and most of the OpenSource software written is GPLed, and we love it.
I don't want to say the BSD license is evil, not at all (while BSD supporters are often less friendly wrt GPL)! Yet the GPL is a better guarantee for our freedom as technological people than the BSD license.
The evolution since the 90s till now has also proven that the GPL license is a more succesfull software license, aside from bringing more freedom to the general public.
Commercially speaking, the BSD license can sometimes be more interesting, however... not in all cases.
The way I see 'giving back' is one in which the freedom of the software is guaranteed, so I don't see any problem there.
Microsoft has just tried another time to:
1) Have an argument in their discussion with government that their license is 'open enough'.
2) Work contradictory to anything remotely touching it's only cash cow: MS Office.
If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
This clearly DOES NOT state that you can append restrictions on the usage of your software.
It's exactly the same reason for which everybody moved from XFree86 to X.org: the obligation to put on it the notice.
It might seem to be of little importance,... just a notice, but it's pandora's box!
So, this brings up the real question: are you an MS fud monkey?
You can only use the 'patented and copyrighted' scheme when you 'include the notices described in the license for Office 2003'.
This makes it GPL incompatible. Period.
Next!
See it at deepspace.linuxbe.com
This means a WISP in a box for everyone - and LinSpot handles the roaming between all linspots and fills your PayPal account while you sleep (and while others roam).
I guess it will take the LinSpot crew a couple of weeks to iron the bugs out and release this for your enjoyement.
They don't do WEP or WPA encryption, and you have to wait about 6 weeks before you get your order, but it works nicely, also behind firewalls... Probably WEP is not such a idea good for latency as well...
WiFi surely is interesting :)
But I guess I'm biased.
... they should have left an option open for people finding holes in the ACTUAL implementation... Now only mathematicians stand a chance - go, go, go, you few good number theoretisists not employed by the NSA! =-= insert favorite conspiricy theory here =-=
Should have upgraded my RH 7.3 box long time ago to something newer... but the Fedora way just didn't seem right to me.
Installing Debian from boot CDs and such didn't sounded so appealing to me,... I guess the OpenSource gods are with me today!
Thanks!
How this is done for SIP-based VoIP - THE STANDARD FOR VoIP. Can be read on this interesting document (page 13 and on are the parts you want to look at).
Basically it works as you described. The third party is called a 'NAT proxy', which forwards the necessary external port numbers and communicate that information with the clients during the communication initiation phase. But it doesn't work for 'Symmetrical NAT'.
For Symmetrical NAT, a so-called 'NAT proxy' is being used to forward the
Price comparisation:
- comparisation of artificially low memory systems as Apples prices are where Apple makes the most on. On the one hand claiming 'we don't want to build ourselves as Apples can't be build, and then going to another store to add memory, just isn't fair when comparing prices.
- Boot-testing the Mac for performance difference with other the HD is a good thing, but the test in the other direction (booting the PC with the other HD might reveal that the bottleneck is in the other direction).
- MacOS X is certainly better in 64bit environments than not wanting to run beta software on a system bought for performance.
- The problem with the Mac is also that the graphics subsystem is already dated. The release cycle of Macs is just too long. When they're first released they -arguably- beat most of the fastest PC's. But the next version is only released at quickest 6 months later, if you compare at that time with latest hardware. Macs just can cope up.
- I also assume that near the end of the cycle, Apple's profit margins are incredible high. It's a very good marketing tactic to keep hardware and software tied to each other, keeping it all under control.
- As I'm typing this on my top-equipped 12" PowerBook, I must admit that MacOS X is a good OS and the hardware is very good (this laptop was cheaper than any comparable hardware at the time I ordered it - not any more at the time when it got delivered)
- And as a rule of thumb, I always say it's better to buy a less expensive system and upgrade it quicker than to go for the fastest and be stuck with it for an extra year.
- Macs also have a better second hand value, and that shouldn't be forgotten when taking the price into account.
- But most performance comparisations clearly SUCK because they tend to be optimised for a certain system (because of lack of knowledge of the party), or highly dependent on release schedules of involved hardware or software.
Gnome is a good choice when you have to choose only one.
KDE is with qt an interesting option when you want to create a simply ported multiplatform application with GUI. But if you look at the currently available important (from target population market share point) applications...
You have to conclude that at this present moment most important Windows applications ARE NOT developed with qt and if they want to port to Linux, they have to choose a new GUI toolkit for their new 'Linux porting department' anyway.
They have to choose for an entirely new GUI toolkit anyway!
Would they choose for a crammy, not as widely used qt-toolkit with some commercial ties (to trolltech in one way or another - at least that's the perception). Or should they choose for an entirely free based, completely new GUI toolkit and different looking from Windows where they wanted to move from away?
The answer is clear. And more importantly the result: all the new 'important' applications are written in GTK and not in QT. The KDE people have written perfectly good QT equivalents. Congratulations. But if you have to choose only one...
It's only the GUI toolkit, not more...
It's more efficient to target your programming differences into other fields! If you look at it from an efficienty point of view!
So, ideally: the qt-designers should move forward to integrate the gtk toolkit into their own. Integration should be the ultimate proof that the OpenSource model works into a level which matches beyond the absurdity level of corporate software development.
Probably I'm dreaming. And probably I used too much drugs...
But what would happen if the KDE-core developer mailinglist and the core GLib mailinglist would suddenly merge into a new LinLib mailinglist....
But I'm probably dreaming out loud...
I would in any case send them a bottle of champaign to celebrate the move!
By Jasper Nuyens.
Founder Life - the linux company
Former GM Europe Linux Services VA Linux Inc.
CEO LinuxBe
CEO LinSpot
So lets ask Google: ... Adobe: 1,910 hits ... The Canopy Group": 12 hits ... Bill Gates": 377 hits
- "Royal Bank of Canada Microsoft": 7,990 hits
- "R.. B.. C.. Compaq": 1,690 hits
- "R.. B.. C.. IBM": 7,960 hits
-
-
-
Hey, found a link there...:
- In July this year, the new appointed Chief Privacy Strategist Peter Cullen for Microsoft came from the Royal Bank of Canada.
- ... Paul Allen: 35 hits
But according to an intersting post on OSNews by Roberto here, "Baystar Capital" and not the Royal Bank should be the connection... but hits there surely have been influenced already with rumor-news...