Regarding the subject: probably because someone among the KDE people thinks s/he can do better than the author of the original app. As far as apps like kopete and kontact go, they actually did do better. Konqueror is still primarily a file manager (excellent browser too, but I guess the "standard" browser will be Firefox in the near future), and significantly better than nautilus as far ergonomics and features go. It also preceded nautilus chronologically.
In addition to DCOP, the upcoming KDE 4 is expected to also support D-BUS, which was designed using DCOP as a model but with the added advantage of having no dependencies,
Thank $deity! KDE would in general benefit from ridding the application programmer from dependencies to GPL'd stuff. KDE "needs" (to the extent any piece of software needs anything) to be able to render Gtk-applications with native LAF, so that the application developers can choose their license freely. I'm not aware if the dependency problem with DCOP relates to Qt, however. Without GPL (and QPL), KDE could have been embraced as the standard Linux desktop environment ages ago. So far it only has the most users, but that's not enough if it's not "strategically viable" (if you work for Trolltech/KDE: please spare the lecture about corps affording $1500/dev/year, we've all seen it).
KDE could really collect the jackpot by allowing development of native KDE apps via Gtk/other LGPL'd lib. I assume QtGtk isn't up to the task yet?
DCOP, BTW, is a very sweet and underadvertised technology. We need DCOP-like scriptability for all the applications. It has a very transparent feel, just like a good Unix methodology should.
Companies like Nokia, Intel etc have a fairly independent investment (or venture capital) fund that makes investments in a very broad portfolio of companies.
Mozilla can't be an "investment" in the sense you are talking about, because they are not-for-profit.
Essentially they are giving money to get some development work done. That's an ethical investment if there ever was one!
Firefox is 4.7 MB (actually with the latest nightlies, there was yet another size decease to 4.4 MB) and Opera is 3.4 MB.
Inspired by this article, I just downloaded Opera for my #2 computer (Debian Sid, w/ 96MB of RAM, somewhat taxed already by other services). The overall experience is quite a bit snappier than with Firefox 0.8. Firefox seems to choke on memory quite a bit more than Opera, even when I have image display enabled on Opera, and disabled on firefox. The playing fields is level in the sense that I'm running Ion3 display manager (which rocks BTW, all resource-starved should check it out ASAP!).
The memory footprints as reported by 'top' don't appear all that different - both have 20MB resident (firefox a bit more), Opera has 22MB shared and Firefox has 29MB (well, that's 8MB difference).
OTOH, on my main machine with abundant ram and other resource, I would never use a non-OSS browser. There it's Firefox all the way.
I have been called stupid by people with less agile minds previously, so I have learned to take it as a compliment.
The open source itself is a lock in since you rely on some developer in some part of the world that you never see. If that person decides to change the license you have nothing to do about it.
If the project is of any global importance, it will be forked (just look at xfree86, oops, x.org). If it is only of importance to your company, you can fork the bugger yourself. Or pay someone to maintain the old version. If a closed source company changes the license you have nothing to do about it.
Linux reduces the number of jobs, since you can't make money off the GPL software directly.
Eh? Linux-the-kernel being GPL has nothing to do with the license of applications that run on it. I've always wondered how some morons actually believe this particular kind of FUD.
Migrating to Linux on Desktop will only affect MSFT bottom line adversely (due to reduced Windows / Office revenues). I can't believe anyone here would mourn falling MSFT revenues. You are either astroturfing, or reading the wrong forum.
Thus only few companies with strong connections can make money.
That's still better than only one company making money, especially when that company is MSFT.
Patriotism means making the best decision for your country.
Indeed it does. Let's not let corrupt officials and lobbyists prevent that.
However, when you do a cost-benefits analyis of open-source software as a whole, you have to take into account user training and support costs.
Don't forget the cost of lock in - it can't be measured on short timerange, but having competition on the market is going to buy you, and the rest of the industry, a lot.
Going for Linux is a no-brainer at least for us europeans. It frees us from an oppressive US monopolist, creates local jobs and generally opens up new business opportunities because, well, Linux doesn't yet have all the software Windows has.
It's time to be a little bit patriotic, people! Asshats that can't learn the few Linux apps they need with a little bit of tutoring could just be fired (now there's a motivation that gets people moving), you should have the best minds working for you in the first place...
I dunno - even the Lisp community seems to think Dylan is dead, so I've put off learning the language.
Dylan also seems needlessly verbose: define funcion? otherwise? end function? Come on... Verbosity is one of the things that suck about Lisp, I would have imagined they would have fixed that.
Well, Python+custom blocks is exactly what I'm looking for. Worked on an embedded platform that involved a lot of custom objects and Python's reliance on its core objects only in blocks was frustrating.
Allrighty then. Do realize, however, that the blocks really aren't that custom. In fact they are just anonymous functions that are written as inlines. So the block behaviour is basically:
def f(x):
print "yielded to block:",x
call_that_takes_block(f)
Ruby allows you to omit naming the function, and writing out the bulk of the block after naming the operation to execute. It's not as "custom" as you possibly think. In fact the Python solution is conceptually more elegant and orthogonal, while the Ruby approach is easier to type and prettier (because of the inlining, and non-significant indentation).
Whoops, I meant to say that I think Ruby might be what I'm looking for.
Depends on whether you care about being able to use the language professionally. Ruby has some things going for it (blocks), but overall the language appears to be less "professional" and mature than Python. Check it out and you'll see what I mean. The few advantages of Ruby don't really outweigh the disadvantages. This applies especially if you are developing a large application, for minor scripts it doesn't matter.
As the poster said, don't believe the hype. People go to ruby from perl because they feel going for Python would be too treasonous in the light of their perl past;-). Ruby is a good language, but mostly because it is almost exactly the same as Python. Python is more mature implementation of the same ideas. Rubyistas just like to present their view like Ruby was different in some meaningful way (sometimes out of ignorance, sometimes out of advocating the language through twisting of the truth). So Ruby is not the "ideal" language you just described, it is still to be implemented.
As for the peculiar syntax, you get used to it rather quickly. Just like with other languages, there are editor tools to help you be productive "in spite of the parenthesis."
The problem with Lisp is readability, now writeability.
Now I'm really confused. Multiple implementations with a common specification hurt Lisp, but Jython and stackless python are not drawbacks for Python?
CPython is still the "standard" implementation of Python. Stackless is just some patches on CPython, and Jython is of interest mostly to Java community. There is no CPython equivalent for Lisp. Jython basically extends the scope of CPython, it doesn't compete with it. The multitude of Lisp implementations don't really have that excuse.
Also, all the Python implementations are Open Source. Lisp community, OTOH, seems to think that only commercial implementations are worthwhile.
Twist it any way you want, one standard open source implementation would guarantee better library and tool support. Then people might even start talking about Lisp standard library, with modern stuff to do things people do with e.g. Python standard library (or perl, or ruby, or...)
I wish my sentiments are not interpreted as attacks against Lisp - I wouldn't mind Lisp getting more popular, and would probably change my current job for a Lisp one if such was available to me. Just pointing out that Common Lisp is not as great as Lispnicks suggest themselves, and Lisp could be much more alive if things were... well, not the way they are.
Is your complaint about Common Lisp based on all Lisp variants? Or is CL especially bad?
No, I just don't think that a proper Lisp has been implemented yet - I'm thinking of a language with all of the semantics of Lisp *plus* easily readable syntactic sugar. I'd like to see a standardized lisp that I can write and read as quickly and Python.
In Python we have a very succesful programming model, in Lisp we have potential for every conceivable programming model. Specializing the Lisp a little bit to optimize for pythonic programming would do a world of good.
I want do do
o = SomeClass()
instead of
(setq o (make-instance SomeClass) )
The latter might be semantically more elegant, but boy, it doesn't flow like the python variant.
As far as non-language-feature issue goes, Lisp does need a better (quantitavely and qualitatively - no "Functional Programming" people but people who can recognize the realities of programming today) community and one standard open source implementation. Availability of commercial implementations just doesn't cut it. And the one open source implementation should run on Windows too (no, Debian doesn't cut it).
Does this mean they actually have developers? Or did they just up the product version number?
We'll never know. It's not like anyone is going to *buy* these products.
Imagine the frustration their developers feel when they put out these products. I can picture an atmosphere of laconic, sarcastic apathy regarding the theoretical users (not that this wouldn't apply to many legitimate sw companies as well;-)
These products were probably roadmapped before hitting rock bottom was inevitable, and the management has no heart to call it quits. Kicking out all the developers before the trial wouldn't look good to the judges - they are probably still trying to give an appearance of a honest-hard working little company whose IP was stolen.
Wasn't Mozilla first conceived in the creepy halls of evil AOL?
I think Netscape didn't belong to AOL back then. Even if it was, AOL is nowhere close to MSFT. As a matter of fact, I can ignore AOL-TW completely in my day to day life. Evil starts to become a problem once it is wildly succesful and has too much power.
I don't need a "soul" in my browser; I need a good, standards-compliant and stable rendering engine in my browser.
For a given developer, the "soul" of the project matters. Ditto for people who build on the platform. Mozilla can render stuff, but so can IE. Still, IE will never have the soul, being conceived in the creepy halls of an evil corporation that want's *your* soul:-).
(Posting from firefox 0.9 running on a soulless platform - chosen by my employer, not me).
Measuring program size in bytes is stupid. Lines of code, though still rife with problems, is a much better measure.
Where program size counts in a scripting language is the time taken to write the program. As someone said recently, "typing is cheap, thinking is expensive". For me it requires 0 seconds of thought and 0.8 seconds of typing to write "import os" in Python if I use something from the os module.
Likewise, using things like regexps from a library necessarily implies some typing (function re.search instead of m//), it doesn't require any thought so the path chosen doesn't impact production time. It does impact the readability which counts too.
I think the referenced "shootout" was a poor idea. Measure things that don't matter, and pretend that they do. A better idea was what was done a while back - measure the size of gzipped source code, which measures the semantic complexity of the code . Python kicked other languages' arses there.
It also seems that IBM is a few years late in that respect. (See: IEEE Standard 1754-1994)
But isn't SPARC (the standardized part) only an instruction set? IBM appears to be opening up much more, revealing details about the actual implementation of the architecture.
What I still can't tell is, will it be possible for a guy with a fab to retool his factory for building IBM CPU's, selling them indefinitely w/o paying the license.
Now *that* would be Open Hardware. Being able to improve the architecture is less interesting than allowing various Asian countries (like China) to switch to Power architecture completely. This would be a very efficient way to combat piratism too in countries where it is a problem - none of Microsoft / closed source software runs on the CPU, so there is nothing to pirate.
Swap caps lock and control
on
Is Caps Lock Dead?
·
· Score: 5, Insightful
More useful than switching with escape is switching caps lock with Control.
You should have:
Option "XkbOptions" "ctrl:swapcaps"
In the InputDevice section for your keyboard (in XF86Config, of course).
Voila'! Ctrl assumes its rightful place on the keyboard. Ergonomic implications are massive.
Equivalent hack is available for NT too. It's done via registry, but I can't be bothered to google for it right now.
That's the way it works. It's meant to ensure that you don't just take pieces of GPL'd code, wrap them in a library, and build code on them that you don't open source.
It can be done if there is a process boundary b/w the modules. I.e. if you use something like CORBA instead of linking.
As I mentioned in the last article about this topic it has nothing to do with GRUB, and happens even if you don't tell Anaconda to partition your system.
Hmm, apparently (from your link) MBR is written even if partitions are not modified. That is positively wicked.
However, my partition hints still apply for installing beta-level distributions, even if not specifically for FC2.
1. Partition in an older, safe system. E.g. knoppix.
2. Install grub in an older, safe system. You should have grub installed already, if you have been using Linux on the machine previously. I never install bootloader anymore, I've been using the same one forever. Just edit the grub config to point to new kernel & root system.
3. Grub should be on the beginning of small boot partition. Never on MBR, if you can avoid it. Always create a 80MB or so partition on the start of every disk, even if you don't plan on using it (yet). This also applies to secondary disks. Kernels should always go to these partitions.
Slashdot Mirror
Regarding the subject: probably because someone among the KDE people thinks s/he can do better than the author of the original app. As far as apps like kopete and kontact go, they actually did do better. Konqueror is still primarily a file manager (excellent browser too, but I guess the "standard" browser will be Firefox in the near future), and significantly better than nautilus as far ergonomics and features go. It also preceded nautilus chronologically.
From TFA:
In addition to DCOP, the upcoming KDE 4 is expected to also support D-BUS, which was designed using DCOP as a model but with the added advantage of having no dependencies,
Thank $deity! KDE would in general benefit from ridding the application programmer from dependencies to GPL'd stuff. KDE "needs" (to the extent any piece of software needs anything) to be able to render Gtk-applications with native LAF, so that the application developers can choose their license freely. I'm not aware if the dependency problem with DCOP relates to Qt, however. Without GPL (and QPL), KDE could have been embraced as the standard Linux desktop environment ages ago. So far it only has the most users, but that's not enough if it's not "strategically viable" (if you work for Trolltech/KDE: please spare the lecture about corps affording $1500/dev/year, we've all seen it).
KDE could really collect the jackpot by allowing development of native KDE apps via Gtk/other LGPL'd lib. I assume QtGtk isn't up to the task yet?
DCOP, BTW, is a very sweet and underadvertised technology. We need DCOP-like scriptability for all the applications. It has a very transparent feel, just like a good Unix methodology should.
Except for the fact that I'll need to keep my television on 24 hours a day to seed.
Aren't you doing that anyway?
Companies like Nokia, Intel etc have a fairly independent investment (or venture capital) fund that makes investments in a very broad portfolio of companies.
Mozilla can't be an "investment" in the sense you are talking about, because they are not-for-profit.
Essentially they are giving money to get some development work done. That's an ethical investment if there ever was one!
Firefox is 4.7 MB (actually with the latest nightlies, there was yet another size decease to 4.4 MB) and Opera is 3.4 MB.
Inspired by this article, I just downloaded Opera for my #2 computer (Debian Sid, w/ 96MB of RAM, somewhat taxed already by other services). The overall experience is quite a bit snappier than with Firefox 0.8. Firefox seems to choke on memory quite a bit more than Opera, even when I have image display enabled on Opera, and disabled on firefox. The playing fields is level in the sense that I'm running Ion3 display manager (which rocks BTW, all resource-starved should check it out ASAP!).
The memory footprints as reported by 'top' don't appear all that different - both have 20MB resident (firefox a bit more), Opera has 22MB shared and Firefox has 29MB (well, that's 8MB difference).
OTOH, on my main machine with abundant ram and other resource, I would never use a non-OSS browser. There it's Firefox all the way.
You are a short sighted idiot.
I have been called stupid by people with less agile minds previously, so I have learned to take it as a compliment.
The open source itself is a lock in since you rely on some developer in some part of the world that you never see. If that person decides to change the license you have nothing to do about it.
If the project is of any global importance, it will be forked (just look at xfree86, oops, x.org). If it is only of importance to your company, you can fork the bugger yourself. Or pay someone to maintain the old version. If a closed source company changes the license you have nothing to do about it.
Linux reduces the number of jobs, since you can't make money off the GPL software directly.
Eh? Linux-the-kernel being GPL has nothing to do with the license of applications that run on it. I've always wondered how some morons actually believe this particular kind of FUD.
Migrating to Linux on Desktop will only affect MSFT bottom line adversely (due to reduced Windows / Office revenues). I can't believe anyone here would mourn falling MSFT revenues. You are either astroturfing, or reading the wrong forum.
Thus only few companies with strong connections can make money.
That's still better than only one company making money, especially when that company is MSFT.
Patriotism means making the best decision for your country.
Indeed it does. Let's not let corrupt officials and lobbyists prevent that.
However, when you do a cost-benefits analyis of open-source software as a whole, you have to take into account user training and support costs.
Don't forget the cost of lock in - it can't be measured on short timerange, but having competition on the market is going to buy you, and the rest of the industry, a lot.
Going for Linux is a no-brainer at least for us europeans. It frees us from an oppressive US monopolist, creates local jobs and generally opens up new business opportunities because, well, Linux doesn't yet have all the software Windows has.
It's time to be a little bit patriotic, people! Asshats that can't learn the few Linux apps they need with a little bit of tutoring could just be fired (now there's a motivation that gets people moving), you should have the best minds working for you in the first place...
It sounds like Dylan is what you are looking for.
I dunno - even the Lisp community seems to think Dylan is dead, so I've put off learning the language.
Dylan also seems needlessly verbose: define funcion? otherwise? end function? Come on... Verbosity is one of the things that suck about Lisp, I would have imagined they would have fixed that.
Allrighty then. Do realize, however, that the blocks really aren't that custom. In fact they are just anonymous functions that are written as inlines. So the block behaviour is basically:
Ruby allows you to omit naming the function, and writing out the bulk of the block after naming the operation to execute. It's not as "custom" as you possibly think. In fact the Python solution is conceptually more elegant and orthogonal, while the Ruby approach is easier to type and prettier (because of the inlining, and non-significant indentation).
As it is with everything, win some, lose some.
Whoops, I meant to say that I think Ruby might be what I'm looking for.
;-). Ruby is a good language, but mostly because it is almost exactly the same as Python. Python is more mature implementation of the same ideas. Rubyistas just like to present their view like Ruby was different in some meaningful way (sometimes out of ignorance, sometimes out of advocating the language through twisting of the truth). So Ruby is not the "ideal" language you just described, it is still to be implemented.
Depends on whether you care about being able to use the language professionally. Ruby has some things going for it (blocks), but overall the language appears to be less "professional" and mature than Python. Check it out and you'll see what I mean. The few advantages of Ruby don't really outweigh the disadvantages. This applies especially if you are developing a large application, for minor scripts it doesn't matter.
As the poster said, don't believe the hype. People go to ruby from perl because they feel going for Python would be too treasonous in the light of their perl past
As for the peculiar syntax, you get used to it rather quickly. Just like with other languages, there are editor tools to help you be productive "in spite of the parenthesis."
The problem with Lisp is readability, now writeability.
Now I'm really confused. Multiple implementations with a common specification hurt Lisp, but Jython and stackless python are not drawbacks for Python?
CPython is still the "standard" implementation of Python. Stackless is just some patches on CPython, and Jython is of interest mostly to Java community. There is no CPython equivalent for Lisp. Jython basically extends the scope of CPython, it doesn't compete with it. The multitude of Lisp implementations don't really have that excuse.
Also, all the Python implementations are Open Source. Lisp community, OTOH, seems to think that only commercial implementations are worthwhile.
Twist it any way you want, one standard open source implementation would guarantee better library and tool support. Then people might even start talking about Lisp standard library, with modern stuff to do things people do with e.g. Python standard library (or perl, or ruby, or...)
I wish my sentiments are not interpreted as attacks against Lisp - I wouldn't mind Lisp getting more popular, and would probably change my current job for a Lisp one if such was available to me. Just pointing out that Common Lisp is not as great as Lispnicks suggest themselves, and Lisp could be much more alive if things were... well, not the way they are.
Is your complaint about Common Lisp based on all Lisp variants? Or is CL especially bad?
No, I just don't think that a proper Lisp has been implemented yet - I'm thinking of a language with all of the semantics of Lisp *plus* easily readable syntactic sugar. I'd like to see a standardized lisp that I can write and read as quickly and Python.
In Python we have a very succesful programming model, in Lisp we have potential for every conceivable programming model. Specializing the Lisp a little bit to optimize for pythonic programming would do a world of good.
I want do do
o = SomeClass()
instead of
(setq o (make-instance SomeClass) )
The latter might be semantically more elegant, but boy, it doesn't flow like the python variant.
As far as non-language-feature issue goes, Lisp does need a better (quantitavely and qualitatively - no "Functional Programming" people but people who can recognize the realities of programming today) community and one standard open source implementation. Availability of commercial implementations just doesn't cut it. And the one open source implementation should run on Windows too (no, Debian doesn't cut it).
What we really need is a meta programming language of which all the other programming languages are special cases.
;-). Common Lisp certainly isn't.
Lisp is it.
Other "modern" (higher level than C) languages are special cases of primordial Lisp, optimized for various niches and programmer mentalities.
This does not imply that Lisp is the best programming language (Python is
Does this mean they actually have developers? Or did they just up the product version number?
;-)
We'll never know. It's not like anyone is going to *buy* these products.
Imagine the frustration their developers feel when they put out these products. I can picture an atmosphere of laconic, sarcastic apathy regarding the theoretical users (not that this wouldn't apply to many legitimate sw companies as well
These products were probably roadmapped before hitting rock bottom was inevitable, and the management has no heart to call it quits. Kicking out all the developers before the trial wouldn't look good to the judges - they are probably still trying to give an appearance of a honest-hard working little company whose IP was stolen.
Do you have a link for that?
Nope, quick googling didn't bring it up. ISTR it was discussed on slashdot.
Wasn't Mozilla first conceived in the creepy halls of evil AOL?
I think Netscape didn't belong to AOL back then. Even if it was, AOL is nowhere close to MSFT. As a matter of fact, I can ignore AOL-TW completely in my day to day life. Evil starts to become a problem once it is wildly succesful and has too much power.
I don't need a "soul" in my browser; I need a good, standards-compliant and stable rendering engine in my browser.
:-).
For a given developer, the "soul" of the project matters. Ditto for people who build on the platform. Mozilla can render stuff, but so can IE. Still, IE will never have the soul, being conceived in the creepy halls of an evil corporation that want's *your* soul
(Posting from firefox 0.9 running on a soulless platform - chosen by my employer, not me).
Measuring program size in bytes is stupid. Lines of code, though still rife with problems, is a much better measure.
Where program size counts in a scripting language is the time taken to write the program. As someone said recently, "typing is cheap, thinking is expensive". For me it requires 0 seconds of thought and 0.8 seconds of typing to write "import os" in Python if I use something from the os module.
Likewise, using things like regexps from a library necessarily implies some typing (function re.search instead of m//), it doesn't require any thought so the path chosen doesn't impact production time. It does impact the readability which counts too.
I think the referenced "shootout" was a poor idea. Measure things that don't matter, and pretend that they do. A better idea was what was done a while back - measure the size of gzipped source code, which measures the semantic complexity of the code . Python kicked other languages' arses there.
(Referring to SPARC:)
It also seems that IBM is a few years late in that respect. (See: IEEE Standard 1754-1994)
But isn't SPARC (the standardized part) only an instruction set? IBM appears to be opening up much more, revealing details about the actual implementation of the architecture.
What I still can't tell is, will it be possible for a guy with a fab to retool his factory for building IBM CPU's, selling them indefinitely w/o paying the license.
Now *that* would be Open Hardware. Being able to improve the architecture is less interesting than allowing various Asian countries (like China) to switch to Power architecture completely. This would be a very efficient way to combat piratism too in countries where it is a problem - none of Microsoft / closed source software runs on the CPU, so there is nothing to pirate.
More useful than switching with escape is switching caps lock with Control.
You should have:
Option "XkbOptions" "ctrl:swapcaps"
In the InputDevice section for your keyboard (in XF86Config, of course).
Voila'! Ctrl assumes its rightful place on the keyboard. Ergonomic implications are massive.
Equivalent hack is available for NT too. It's done via registry, but I can't be bothered to google for it right now.
That's the way it works. It's meant to ensure that you don't just take pieces of GPL'd code, wrap them in a library, and build code on them that you don't open source.
It can be done if there is a process boundary b/w the modules. I.e. if you use something like CORBA instead of linking.
When does firefox/fire* get renamed "mozilla browser"?
As I mentioned in the last article about this topic it has nothing to do with GRUB, and happens even if you don't tell Anaconda to partition your system.
Hmm, apparently (from your link) MBR is written even if partitions are not modified. That is positively wicked.
However, my partition hints still apply for installing beta-level distributions, even if not specifically for FC2.
1. Partition in an older, safe system. E.g. knoppix.
2. Install grub in an older, safe system. You should have grub installed already, if you have been using Linux on the machine previously. I never install bootloader anymore, I've been using the same one forever. Just edit the grub config to point to new kernel & root system.
3. Grub should be on the beginning of small boot partition. Never on MBR, if you can avoid it. Always create a 80MB or so partition on the start of every disk, even if you don't plan on using it (yet). This also applies to secondary disks. Kernels should always go to these partitions.