It was certainly not a traditional GPL software development toolkit in the sense of the restrictions placed on the developer.
Of course it was, it's the GPL, nothing more, nothing less.
What you are referring to is a condition of the commercial license, (to prevent you from finally buying 1 single license to release your 20-man-years-application commercially). You are free to accept, reject, or try and renegotiate the conditions of this commercial license. If you don't like them, stick with the GPL, it's your choice.
Practicality of enforcing such a restriction in the commercial license notwithstanding.
An example : in Holland you can get dialysis (if you need this, you die without). However once you turn 65, you cannot get dialisys anymore in any hospital, at any price. Anyone with kidney problems (which is a lot of people) ages to 65 years and 6 months or so in Holland, and not a day older. If you try to buy it, which is obviously not cheap, you run the risk of getting arrested, both the patient and the docter, and getting incarcerated WITHOUT dialisys. The one guy they did this to did not survive to see his trial. Isn't socialist healthcare grand ?
2910 people disagree with you (out of the total of ~5600 Dutch people dependant on dialysis for survival).
Re:Only works if it's default install
on
TrueCrypt 6.0 Released
·
· Score: 4, Insightful
Stop being an idiot and read up on it. You can *not* tell. And it certainly does not show up as free space. You can *not* prove OR disprove the existence of another hidden partition. Period. "Trained to look for it", oh please.
Viacom wants the data to prove that infringing material is more popular than user-created videos, which could be used to increase Google's liability if it is found guilty of contributory infringement.
So anonymize the data. Ask your friendly local CS student for instructions. You can get all your statistics from that.
Oh, that isn't actually the reason you want the data? Yeah, thought so. DIAF
He enrolled in Helsinki in 1988, announced Linux in 1991, got the BSc in 1995, and the MSc in 1997 (having worked odd jobs at the University) and only then moved to the "real money job". I guess we missed the part where he moved back from silicon valley to finland "much later" to study for a few more years?
You are being awfully naive here. Personal details are worth about US$50 each to identity fraud gangs. 10,000 personal details times US$50 is half a million bucks, and that buys a lot of supercomputer time. Any encryption can be brute forced given enough brute force.
You keep saying that. Maybe you want to run the numbers sometime? Something like all the computing power in the world in constant use for X thousand years? Barring a fundamental flaw in the algorithm, or a botchy implementation (say generating your keys on Debian) there is no way this is brute forcable in anyones lifetime. It's just math. It's your random claim the russian maffia can break any encryption, versus math. I know whose side I am on.
Half a million bucks buys you a 56 bit DES message in under 24 hours. Note that an extra bit does not double the effort, it squares it. Do the math.
"Apparently, OpenSSL was using uninitialized memory as a source of randomness. Sounds bad to me. What if one OS initialises that memory to a known value? You might have an OS specific systematic vulnerability."
Will people give this a rest already? Worst case: memory is 100% predictable, entropy is 0, TA-DA, same result as initializing the memory to something before use. Best case: memory is 100% random. Likely typical case, somewhere in between. There are some free extra bits of entropy if you're lucky, and *no loss* if you're not, so it's kept in.
Now suppose that an API requires that the audio data being passed to it is in my compressed audio format (the one on which I have a patent). The EU competition authority cannot say that I should not recieve royalties on people using my audio compression algorithm. They can even say I'm charging too much, they can decide that 0.0000001c per server is too much, but they cannot tell me to give it away for free (Without opening themselves up to a massive internal fight with the EU patent office)
Which is why the EU patent law says that if using the patent is necessary for interoperability, tough bananas for you. Add an Ogg Vorbis interface so people dont HAVE to license your patent just to interoperate.
Actually it is a hardware signal and unprivilidged programs have no way of intercepting it. Contrast to "type your password and hit enter" where a fake login screen could trick people. Good luck writing a fake "press ctr-alt-delete to log in" app:-)
1441 specifically said, and was only ever accepted because of this, that another resolution would HAVE to be required to allow force to be used. It was VERY VERY specific about this.
Frits Bolkenstein of course being the famous Dutch politician who spent a decade or so sitting in the government lobbying on behalf of a pharmaceutical company (was a funny situation when it was discovered and all the commissions/bonuses paid etc were made public.He's quite cheap apparently. Of course he didn't resign or anything). So this is where he went. Great.
... nor does KDE have a more advanced infrastructure than GNOME.
I never claimed it did.
Bonoboising X-Chat (making it a component that GNOME apps can use) isn't that hard.
Nor did I claim that. My point was that if gnome would be bonoboising (nice verb:) apps people would also use the NIH syndrome argument (and that therefore it's not a completely valid argument).
I know it's "the thing" for KDE zealots to claim that app development is faster with KDE
Again, I never claimed that. Nobody said "faster", just "fast". It's a KDE article, so you get KDE posts. That doesn't imply bad things about Gnome.
Seriously.. KDE has the worst case of NIH I've ever seen. The Gnome project has no problem adopting existing technology and projects. Galeon, the Gnome browser, uses Mozilla, they turned AbiWord into a Gnome app (it didn't start out as a Gnome app).. but KDE has to reinvent the wheel. "AbiWord? Nah, we're not going to make KDE bindings for it, no matter how modular it is! We're going to start from scratch".
While you definately have a point, it's also the developer's choice. Most KDE development is in framework, i.e. you can embed the Kmail component into Kaplan. The requirement for this is that the component was designed with this framework in mind, or is ported to do so.
Application development with KDE is fast, because you get to build on a great framework with many components to choose from.
There is very little duplicate code in KDE, although much of the KDE code does the same as similar code in other projects. What you have to remember is that this KDE code can be plugged into any other KDE program, and KMail for example is a shell for the (now) KMail component which is built on SMTP, POP, IMAP, etc kio-slaves.
KDE's architecture is very advanced, and very well planned. To make full use of it, it needs to be considered from the start. Hence re-doing something for KDE as opposed to slapping KDE menu's on an existing program.
The reason KMail is part of KDE is that any KDE app can embed and control KMail components and vice versa. If you need IMAP in your application, it's trivial to add it.
The reason Xchat is part of Gnome is that it uses Gtk and some other Gnome libs. If you want to include IRC in your Gnome app (along with all Xchat functionality), is it also trivial?
There's a difference. And no this does not say anything about wether Gnome or KDE is better, bless both projects. I'm just pointing out there *are* others reasons than NIH.
The different "modules", i.e. the mailer part, the calendering part, etc, are implemented as KParts. This means that you will be able to specify which KPart you want to embed for what functions (similar to how you can choose which text editing widget you want to use, KVim as Konqueror's textarea anyone?).
It also means it is mostly "just" a shell around existing components, not another re-invented wheel. Not more bloated than running the components seperately (probably less overhead even, because you only need one KApplication instance).
In a sense it is tying existing technologies together (think back-end here too, using Open Source tech) into a slick package.
You don't *have* to use it, but corporate settings will probably like it.
As for your tax money (you live in Germany?) paying for the development, would you rather see the money go to Microsoft and get a product in return which will need upgrading eventually? Oh, and *you* personally don't get anything out of it, whereas now you get to use this development to your heart's content. And even if you don't like to use it personally, you'll be able to deploy it for your clients so they can at least use open technology).
To loosely quote Miguel de Icaza: it's not about making money, it's about *solving the problem*.
Personally, I'd happily pay 1% extra taxes to Germany (and I don't even live there!) to be used on similar projects because they benefit *everyone* (read below before you say "except software companies").
You see, times change. It used to be good business selling boxed software, but it's becoming less and less so. The trick now lies in providing a *service*. There will always be a need for skilled IT people, but to provide services, not simply products. I.e. a company specifies what their infrastructure needs to do, what requirements there are, etc, and you implement it using open source technology. There are no purchase or license fees (apart from specialised high-end software) and the value is in how well you set things up. It works for me:)
What when (and note that I don't say "if") some unscrupulous criminals will decide to "steal" the authentication token? That means, they cut the poor guy's finger! That's why in many high security institutions fingerprint authentication is frowned upon.
A good fingerpring scanner will also look at your biorythm, i.e. a pulse, it will not work with a "dead" finger.
Actually, some things get easier. You can now buy USB support chips, or even PIC's with USB support built in (both cheaply), and connect your EE project straight to your computer, without worrying wether you are going to blow up your mobo (ISA/PCI).
Write a driver for your device (based on the USB ID) for whatever OS you use, and roll on. You get true plug and play, don't run out of space, can power small projects directly off the USB, etc.
So.. forget PCI. Go for USB. I don't remember the URL (typical) but there is a website with a full tutorial about building a USB device, step by step, including diagrams and sourcecode.
Re:Have they fixed the fonts?
on
KDE 3.0 is Out
·
· Score: 1
Anti-aliasing only used to work for certain fonts, and then others didn't work, etc etc, I never got it working properly so I just didn't use AA (then there shouldn't be any probs).
Right now I just finished compiling RC3 for Gentoo (and my first konqie test to slashdot showed KDE 3 released!) and the font manager is way cool. All fonts work properly and you can customize everything completely, which fonts, which sizes, etc.
I have to say this looks *damn* good! Big thanks to the KDE people! KDE 3 is wonderful!
Mozilla, and apps based on its tech, some Perl IDE (Can't remember the name right now) use XUL files to describe behaviour and appearance of widgets, DTD files to define different locales, and use javascript for their logic.
I am using a US keyb layout now while used to a Finnish one, so I am not getting anywhere fast with this post, but have a look at the Moz stuff. It's perfectly possible (if not done already) to write for example an Office app using just those Moz tools. Including very rich features (HTML content, pictures, plugins, etc), drag and drop, clipboard, etc.
The Java VM was designed to run Java while the CLR was designed to be language agnostic. The fact that C++ can run on the CLR is a testament to this fact.
Not the C++ you know and love. Nowhere near, for example no multiple inheritance. A stripped down and modified version. Think C# but using C++ syntax.
It is actually the SpeedStep (CPU changing speed) that kills the box when the power plug is removed.
According to the LKML at the time I asked (more than a year ago) they said Intel has not documented speedstep sufficiently.
I just changed the BIOS to always run in 700MHz (and thus disable speedstep) and haven't had a problem since.
I did have to upgrade the BIOS to get support for the APM battery status call, so I've only got APM enabled, suspend-to-memory, and all is good, never crashes.
Slashdot Mirror
It was certainly not a traditional GPL software development toolkit in the sense of the restrictions placed on the developer.
Of course it was, it's the GPL, nothing more, nothing less.
What you are referring to is a condition of the commercial license, (to prevent you from finally buying 1 single license to release your 20-man-years-application commercially). You are free to accept, reject, or try and renegotiate the conditions of this commercial license. If you don't like them, stick with the GPL, it's your choice.
Practicality of enforcing such a restriction in the commercial license notwithstanding.
An example : in Holland you can get dialysis (if you need this, you die without). However once you turn 65, you cannot get dialisys anymore in any hospital, at any price. Anyone with kidney problems (which is a lot of people) ages to 65 years and 6 months or so in Holland, and not a day older. If you try to buy it, which is obviously not cheap, you run the risk of getting arrested, both the patient and the docter, and getting incarcerated WITHOUT dialisys. The one guy they did this to did not survive to see his trial. Isn't socialist healthcare grand ?
source: http://www.nierstichting.nl/ziekte/feiten_en_cijfers
Dialysepatiënten per leeftijdsgroep (2006)
Leeftijd Aantal Percentage
0-15 37 1%
16-44 812 14%
45-64 1.898 34%
65-74 1.439 25%
75+ 1.471 26%
2910 people disagree with you (out of the total of ~5600 Dutch people dependant on dialysis for survival).
Stop being an idiot and read up on it. You can *not* tell. And it certainly does not show up as free space. You can *not* prove OR disprove the existence of another hidden partition. Period. "Trained to look for it", oh please.
Viacom wants the data to prove that infringing material is more popular than user-created videos, which could be used to increase Google's liability if it is found guilty of contributory infringement.
So anonymize the data. Ask your friendly local CS student for instructions. You can get all your statistics from that.
Oh, that isn't actually the reason you want the data? Yeah, thought so. DIAF
He enrolled in Helsinki in 1988, announced Linux in 1991, got the BSc in 1995, and the MSc in 1997 (having worked odd jobs at the University) and only then moved to the "real money job". I guess we missed the part where he moved back from silicon valley to finland "much later" to study for a few more years?
Ugh, yes, sorry.
What I meant is that every extra bit doubles the effort, i.e. going from 128 to 256 bits is not doubling the effort, it is squaring it.
You keep saying that. Maybe you want to run the numbers sometime? Something like all the computing power in the world in constant use for X thousand years? Barring a fundamental flaw in the algorithm, or a botchy implementation (say generating your keys on Debian) there is no way this is brute forcable in anyones lifetime. It's just math. It's your random claim the russian maffia can break any encryption, versus math. I know whose side I am on.
Half a million bucks buys you a 56 bit DES message in under 24 hours. Note that an extra bit does not double the effort, it squares it. Do the math.
"Apparently, OpenSSL was using uninitialized memory as a source of randomness.
Sounds bad to me. What if one OS initialises that memory to a known value? You might have an OS specific systematic vulnerability."
Will people give this a rest already? Worst case: memory is 100% predictable, entropy is 0, TA-DA, same result as initializing the memory to something before use. Best case: memory is 100% random. Likely typical case, somewhere in between. There are some free extra bits of entropy if you're lucky, and *no loss* if you're not, so it's kept in.
echo "cfq" > /sys/block/hda/queue/scheduler
nice -n 19 ionice -c3 emerge -uav world
Both CPU and I/O running at idle priorities
(requires 2.6.13+, and schedutils for ionice)
Which is why the EU patent law says that if using the patent is necessary for interoperability, tough bananas for you. Add an Ogg Vorbis interface so people dont HAVE to license your patent just to interoperate.
You can do this today in Quanta. (see http://quanta.sourceforge.net)
Actually it is a hardware signal and unprivilidged programs have no way of intercepting it. Contrast to "type your password and hit enter" where a fake login screen could trick people. Good luck writing a fake "press ctr-alt-delete to log in" app :-)
Frankly anyone bringing up 1441 is an ass.
Frits Bolkenstein of course being the famous Dutch politician who spent a decade or so sitting in the government lobbying on behalf of a pharmaceutical company (was a funny situation when it was discovered and all the commissions/bonuses paid etc were made public.He's quite cheap apparently. Of course he didn't resign or anything). So this is where he went. Great.
I never claimed it did.
Bonoboising X-Chat (making it a component that GNOME apps can use) isn't that hard.
Nor did I claim that. My point was that if gnome would be bonoboising (nice verb :) apps people would also use the NIH syndrome argument (and that therefore it's not a completely valid argument).
I know it's "the thing" for KDE zealots to claim that app development is faster with KDE
Again, I never claimed that. Nobody said "faster", just "fast". It's a KDE article, so you get KDE posts. That doesn't imply bad things about Gnome.
While you definately have a point, it's also the developer's choice. Most KDE development is in framework, i.e. you can embed the Kmail component into Kaplan. The requirement for this is that the component was designed with this framework in mind, or is ported to do so.
Application development with KDE is fast, because you get to build on a great framework with many components to choose from.
There is very little duplicate code in KDE, although much of the KDE code does the same as similar code in other projects. What you have to remember is that this KDE code can be plugged into any other KDE program, and KMail for example is a shell for the (now) KMail component which is built on SMTP, POP, IMAP, etc kio-slaves.
KDE's architecture is very advanced, and very well planned. To make full use of it, it needs to be considered from the start. Hence re-doing something for KDE as opposed to slapping KDE menu's on an existing program.
The reason KMail is part of KDE is that any KDE app can embed and control KMail components and vice versa. If you need IMAP in your application, it's trivial to add it.
The reason Xchat is part of Gnome is that it uses Gtk and some other Gnome libs. If you want to include IRC in your Gnome app (along with all Xchat functionality), is it also trivial?
There's a difference. And no this does not say anything about wether Gnome or KDE is better, bless both projects. I'm just pointing out there *are* others reasons than NIH.
The different "modules", i.e. the mailer part, the calendering part, etc, are implemented as KParts. This means that you will be able to specify which KPart you want to embed for what functions (similar to how you can choose which text editing widget you want to use, KVim as Konqueror's textarea anyone?).
:)
It also means it is mostly "just" a shell around existing components, not another re-invented wheel. Not more bloated than running the components seperately (probably less overhead even, because you only need one KApplication instance).
In a sense it is tying existing technologies together (think back-end here too, using Open Source tech) into a slick package.
You don't *have* to use it, but corporate settings will probably like it.
As for your tax money (you live in Germany?) paying for the development, would you rather see the money go to Microsoft and get a product in return which will need upgrading eventually? Oh, and *you* personally don't get anything out of it, whereas now you get to use this development to your heart's content. And even if you don't like to use it personally, you'll be able to deploy it for your clients so they can at least use open technology).
To loosely quote Miguel de Icaza: it's not about making money, it's about *solving the problem*.
Personally, I'd happily pay 1% extra taxes to Germany (and I don't even live there!) to be used on similar projects because they benefit *everyone* (read below before you say "except software companies").
You see, times change. It used to be good business selling boxed software, but it's becoming less and less so. The trick now lies in providing a *service*. There will always be a need for skilled IT people, but to provide services, not simply products. I.e. a company specifies what their infrastructure needs to do, what requirements there are, etc, and you implement it using open source technology. There are no purchase or license fees (apart from specialised high-end software) and the value is in how well you set things up. It works for me
A good fingerpring scanner will also look at your biorythm, i.e. a pulse, it will not work with a "dead" finger.
Write a driver for your device (based on the USB ID) for whatever OS you use, and roll on. You get true plug and play, don't run out of space, can power small projects directly off the USB, etc.
So.. forget PCI. Go for USB. I don't remember the URL (typical) but there is a website with a full tutorial about building a USB device, step by step, including diagrams and sourcecode.
Heh, I can tell you are not from Australia :-)
Right now I just finished compiling RC3 for Gentoo (and my first konqie test to slashdot showed KDE 3 released!) and the font manager is way cool. All fonts work properly and you can customize everything completely, which fonts, which sizes, etc.
I have to say this looks *damn* good! Big thanks to the KDE people! KDE 3 is wonderful!
Mozilla, and apps based on its tech, some Perl IDE (Can't remember the name right now) use XUL files to describe behaviour and appearance of widgets, DTD files to define different locales, and use javascript for their logic.
I am using a US keyb layout now while used to a Finnish one, so I am not getting anywhere fast with this post, but have a look at the Moz stuff. It's perfectly possible (if not done already) to write for example an Office app using just those Moz tools. Including very rich features (HTML content, pictures, plugins, etc), drag and drop, clipboard, etc.
Not the C++ you know and love. Nowhere near, for example no multiple inheritance. A stripped down and modified version. Think C# but using C++ syntax.
The nVidia binary drivers wouldn't load in a 2.4 kernel with the preemptive patch. Did I miss something? Maybe I should try again :-)
According to the LKML at the time I asked (more than a year ago) they said Intel has not documented speedstep sufficiently.
I just changed the BIOS to always run in 700MHz (and thus disable speedstep) and haven't had a problem since.
I did have to upgrade the BIOS to get support for the APM battery status call, so I've only got APM enabled, suspend-to-memory, and all is good, never crashes.