I'm a web developer. I write tons of JavaScript / CSS code each day. I have compatibility at the top of my priority list. I try to code to standards, using Firefox as the testbed. Then I make it compatible with IE. Finally, I test with Konqueror and Opera. You know how often I have to recode something to make it work with Konqueror? Maybe once in a month, minor changes, no more than a few minutes work.
You know how often I have to recode for Opera? Twice so far, in the last three years.
When you mostly code to standards, and don't use browser detects but functionality detects to get stuff working with IE, it's very rare that you need any change at all for Opera or KHTML. More fragmentation is good, but not because of the web pages and web applications. It's good because it gives competition a boost and we might actually see innovation in the browser field (SVG, CANVAS, OpenGL:-P ). We won't see more web development.
(At least, not from the ones who already grasp the bottom line. Maybe from the ones who now only code for IE.)
I have used FreeBSD with KDE at work for over three years now. Planning to migrate to openSUSE. I've never quite grasped why anyone could think that Linux is not ready for the desktop. In my opinion, it has been for years.
I'm sorry, but your review is more than a year old. For example: it talks about patching the kernel, which isn't necessary anymore (since it uses LSM now).
Can you confirm that the situation is still like you described? I have no clue at all (been using openSUSE for less than a month now), but I won't take any advise from anyone who points to a year old article about a project under active (heavy) development.
I would release software I've written under the GPL any time. But sometimes (OpenSSH, FreeBSD) it might be more reasonable to release it under a less restrictive license.
Thing is: BSD and GPL define what might be done with the source. It's not so much that BSD is about total freedom, it's about giving away the right to close the source. GPL restricts that.
I agree with you when someone stands up and shouts at the person who actually closes the source. They are just using their rights. But that is not the point I tried to make: if someone takes the code, closes it and earns (lots of) money with it, it's not unreasonable to expect a donation (as a token of appreciation and as a push to get better versions in the future). It might even be called immoral not to give a donation (accepting a present without saying: "gosh, thanks!").
We all like to be thanked for our work. GPL demands thanks. BSD leaves it up to the user. Both complain when thanks are not received, the BSD crowd vocally in disappointment and the GPL crowd in court (whenever able). That is the real difference.
When someone takes BSD-licensed code like OpenSSH and releases it proprietary, they may do so. No harm done, "we" still have the original. It is a sign of bad morals when they don't do something back though, and that may be said. Which is exactly what Theo did.
Furthermore, when there is a bug in the original code, it is certainly not up to the devs of that code to inform all the deriatives. That would be funny: someone takes your hard work, does nothing in return and people still expect that you take responsibility for that.
BSD is like: here you are, do what you want, as long as you give credit. It would, however, be extremely nice when there is something done in return, for example financial support. This would create a certain symbiose: Sun makes SunSSH, and gives credit and finances to OpenSSH, so that OpenSSH can continue to improve while SunSSH can use those improvements.
What Theo said was this: sure they can use it, but I find it sad that they won't return any favor. He is completely right with that statement.
If OpenSSH was released under the GPL or even the LGPL, either telnet would still be the #1 app for remote control or a myriad of proprietary protocols would exist for that.
You have to realize that while a majority of people have an IQ of 100 and up, some don't. And some of those do use the internet.
The point is that there are people out there who are just to stupid to think about phishing. The problem is getting them to install an anti-phishing tool. In some case one can do that for them, which might be helpfull. There is where such a thing is needed.
If you can get my mom to understand that sentence, I will pay you $500.
Ridiculous. End-users shouldn't be afraid nor bothered with recompiling. It's the makers of a software packages that shouldn't be afraid but should just write decent code. Designing for a VM because it is easier to deploy cross-platform is just laziness.
True, for webpages. But the summary (haven't read TFA yet) talks about applications. Now that's more than webpages.
Consider a chat-application (I've written and I'm maintaining one) based on AJAX. To feel responsive, every parttaker in a chatsession should at least fire one XMLHttpRequest each second. More would be nice. Lighttpd can handle that with two or three "chatters" online. More becomes painstaking. The same is true with Apache 2 using the default settings, but you can increase the maximum it can handle by tweaking several settings.
I've seen Apache being forced on its knees with ten connections issuing two request per second each. Lighttpd wouldn't even dream of doing that. After some tweaking, Apache could easily handle 40 of those connections. The bottleneck then is memory usage at the PHP side of the coin. So I'm off to RTFA to see if they have any solution on that.
Sure, static content should be accessible. But that is a thing of the past (or will be). I'm building webapps which are all about realtime interacting with the visitor. There is no simple way of doing that without JavaScript, so that is mandatory.
It's not: "Hey! With JavaScript enabled you get to enjoy these cool mouseover effects I just build!"
It's: "With JavaScript enabled you get to experience a whole new way of accessing information and communicating with us."
Completely different story. Now, offcourse that should all be complementary to the basic information on a website, and that information should always be accessible.
Blocking JavaScript is for those that view the web as a giant book, full of text and pictures. Maybe a form here or there, or a decently build webshop. Nothing realtime, nothing changing quickly, nothing fully dynamic. It's the stoneage compared to the Roman civilisation. And I mention ancient times because it is going to be much more intense.
Offcourse, JavaScript can also be blocked to artificially create an illusion of choice (ie, turn it on when you want it). But that carries the risk of missing the choice at all: most of the time you won't even notice that you are missing something.
As I said, the point is not TV dissapearing, but TV to be replaced. Offcourse life wasn't less social before the introduction of the TV, but at least the TV (with few enough channels) still functions as a glue for socialisation sometimes. Watching shows on demand using the internet will make that dissapear.
If TV would just dissapear, your argument stands: it's back to the 50's then. But that is not the case.
Slashdot Mirror
ME TOO!!!
Care to elaborate why to avoid RPM? Curious FreeBSD-to-openSUSE switcher want to know...
Wine?
Only 3000 lines of JavaScript code in the current project :-)
Ah, so Mac OS X is not ready too. Good to know... Will you tell the Apple fanbois?
I'm a web developer. I write tons of JavaScript / CSS code each day. I have compatibility at the top of my priority list. I try to code to standards, using Firefox as the testbed. Then I make it compatible with IE. Finally, I test with Konqueror and Opera. You know how often I have to recode something to make it work with Konqueror? Maybe once in a month, minor changes, no more than a few minutes work.
:-P ). We won't see more web development.
You know how often I have to recode for Opera? Twice so far, in the last three years.
When you mostly code to standards, and don't use browser detects but functionality detects to get stuff working with IE, it's very rare that you need any change at all for Opera or KHTML. More fragmentation is good, but not because of the web pages and web applications. It's good because it gives competition a boost and we might actually see innovation in the browser field (SVG, CANVAS, OpenGL
(At least, not from the ones who already grasp the bottom line. Maybe from the ones who now only code for IE.)
I have used FreeBSD with KDE at work for over three years now. Planning to migrate to openSUSE. I've never quite grasped why anyone could think that Linux is not ready for the desktop. In my opinion, it has been for years.
I'm sorry, but your review is more than a year old. For example: it talks about patching the kernel, which isn't necessary anymore (since it uses LSM now).
Can you confirm that the situation is still like you described? I have no clue at all (been using openSUSE for less than a month now), but I won't take any advise from anyone who points to a year old article about a project under active (heavy) development.
I would release software I've written under the GPL any time. But sometimes (OpenSSH, FreeBSD) it might be more reasonable to release it under a less restrictive license.
Thing is: BSD and GPL define what might be done with the source. It's not so much that BSD is about total freedom, it's about giving away the right to close the source. GPL restricts that.
I agree with you when someone stands up and shouts at the person who actually closes the source. They are just using their rights. But that is not the point I tried to make: if someone takes the code, closes it and earns (lots of) money with it, it's not unreasonable to expect a donation (as a token of appreciation and as a push to get better versions in the future). It might even be called immoral not to give a donation (accepting a present without saying: "gosh, thanks!").
We all like to be thanked for our work. GPL demands thanks. BSD leaves it up to the user. Both complain when thanks are not received, the BSD crowd vocally in disappointment and the GPL crowd in court (whenever able). That is the real difference.
When someone takes BSD-licensed code like OpenSSH and releases it proprietary, they may do so. No harm done, "we" still have the original. It is a sign of bad morals when they don't do something back though, and that may be said. Which is exactly what Theo did.
Furthermore, when there is a bug in the original code, it is certainly not up to the devs of that code to inform all the deriatives. That would be funny: someone takes your hard work, does nothing in return and people still expect that you take responsibility for that.
BSD is like: here you are, do what you want, as long as you give credit. It would, however, be extremely nice when there is something done in return, for example financial support. This would create a certain symbiose: Sun makes SunSSH, and gives credit and finances to OpenSSH, so that OpenSSH can continue to improve while SunSSH can use those improvements.
What Theo said was this: sure they can use it, but I find it sad that they won't return any favor. He is completely right with that statement.
If OpenSSH was released under the GPL or even the LGPL, either telnet would still be the #1 app for remote control or a myriad of proprietary protocols would exist for that.
But does it run...
ah, to hell with all these "obs"!
There are more than two choices you know...
I heard Microsoft is looking for someone to sort out their patent archive... 235 are missing, you see...
You have to realize that while a majority of people have an IQ of 100 and up, some don't. And some of those do use the internet.
The point is that there are people out there who are just to stupid to think about phishing. The problem is getting them to install an anti-phishing tool. In some case one can do that for them, which might be helpfull. There is where such a thing is needed.
You're lucky. I have. External booting (LiveCD, USB) is then the answer. BartsPE is nice, Knoppix can do the trick too, if you know where to look.
With the right tools, this gadget might be helpfull. But a thumbdrive loaded with Linux is just as handy, and less costly.
Why use ZFS? As far as I can see, I find no reason not to use GEOM and UFS2 or something like that...
(This question is serious. I just wonder why ZFS is chosen for this solution. Anyone knows?)
Guys! A Microserf! Here!
True, for webpages. But the summary (haven't read TFA yet) talks about applications. Now that's more than webpages.
Consider a chat-application (I've written and I'm maintaining one) based on AJAX. To feel responsive, every parttaker in a chatsession should at least fire one XMLHttpRequest each second. More would be nice. Lighttpd can handle that with two or three "chatters" online. More becomes painstaking. The same is true with Apache 2 using the default settings, but you can increase the maximum it can handle by tweaking several settings.
I've seen Apache being forced on its knees with ten connections issuing two request per second each. Lighttpd wouldn't even dream of doing that. After some tweaking, Apache could easily handle 40 of those connections. The bottleneck then is memory usage at the PHP side of the coin. So I'm off to RTFA to see if they have any solution on that.
$ 108,000,000.00
Use the Preview Button! Check those URLs!
That is, unless you WANT us to go to that add-infested parked domain.
SATA speeds are 1.5 to 3.0 Gbps...
But the archive is part of the web, no? As is the Google cache...
Sure, static content should be accessible. But that is a thing of the past (or will be). I'm building webapps which are all about realtime interacting with the visitor. There is no simple way of doing that without JavaScript, so that is mandatory.
It's not: "Hey! With JavaScript enabled you get to enjoy these cool mouseover effects I just build!"
It's: "With JavaScript enabled you get to experience a whole new way of accessing information and communicating with us."
Completely different story. Now, offcourse that should all be complementary to the basic information on a website, and that information should always be accessible.
Blocking JavaScript is for those that view the web as a giant book, full of text and pictures. Maybe a form here or there, or a decently build webshop. Nothing realtime, nothing changing quickly, nothing fully dynamic. It's the stoneage compared to the Roman civilisation. And I mention ancient times because it is going to be much more intense.
Offcourse, JavaScript can also be blocked to artificially create an illusion of choice (ie, turn it on when you want it). But that carries the risk of missing the choice at all: most of the time you won't even notice that you are missing something.
As I said, the point is not TV dissapearing, but TV to be replaced. Offcourse life wasn't less social before the introduction of the TV, but at least the TV (with few enough channels) still functions as a glue for socialisation sometimes. Watching shows on demand using the internet will make that dissapear.
If TV would just dissapear, your argument stands: it's back to the 50's then. But that is not the case.