Fifthly, the poster specifically said that lawyers would need to be consulted before code could be released. Lawyers are at least as expensive as coders, so your "Net loss: $0" is certainly not accurate.
How about this scenario. The figures could go either way, but it's important to note which figures are one-time and which are recurring...
Releasing code: - Lawyer time ($nnn, one-time) - Programmer time to work with external maintainer to get patches accepted into the external source tree ($mmm, one-time, probably not a terribly large amount of time)
Keeping code internal: - No lawyer time ($0) - No up-front programmer time ($0) - Programmer time to re-integrate local changes into new externally-released version of program ($ppp, recurring, and probably much larger than $mmm, at least).
Now, depending on the lawyer cost, a single upgrade might or might not work out cheaper if the code is kept internally. But eventually a recurring cost is guaranteed to come out greater than any one-time cost. This is even more true if the legal work can be done once to cover all future open source contributions, so that the lawyer cost can be split across multiple applications.
What a lot of managers don't realize is that maintaining a fork of a program's source code is expensive. As your codebase diverges from the external one, important bugfixes applied to the latter become harder and harder to apply to your local copy, taking more and more programmer time to keep up. Paying a little more up front in that situation is just good sense.
Beyond that, since the implication of the article is that these are changes to existing projects, tell them that keeping a locally-modified version will require substantial maintenance just to upgrade to each new release. In other (buzz)words, emphasize the large recurring maintenance cost of the status quo.
Paying once for the time spent in politics with the external maintainers to get the patches integrated will probably be less than the cost of upgrading to a new external release even once.
The other thing to ask is whether the company expected to make any money directly off the code changes in the first place. This may be "Corporate IP" that has a theoretical monetary "value", but in most cases the company has no plans on actually realizing that value. Point out that you aren't really giving away any value if you weren't planning on getting any dollars out of that value in the first place.
They might respond to that with "well, we should go and figure out how to realize that value, then". If they do, you might want to actually go through the motions of exploring how to extract the value. It should be fairly obvious without biasing your results that there really isn't any way to profitably extract value from a few random patches to an open source project. Ask if they really want to get into the software-selling business. Figure out how much it would cost to create the infrastructure and legal red tape to do this (count people's hours at billable rate if you like), and guesstimate an optimistic figure for how much you could sell the patches for, and how many copies you would sell. Present all of this in a nice presentation showing how you'd actually lose a substantial amount if you tried to do it.
Given all this background, you can present the three alternatives: Keep the code private (large recurring maintenance cost), sell the code (certainly a negative profit), or give the code away (small one-time integration cost). The desired course of action should be obvious:)
This all depends on what you are comparing to. If the alternative to the Open Source software was proprietary software, your argument falls apart.
Suppose that the alternative to GNU SurfWriter was Microsoft Surf. Would you have had to release your changes ("IP") to the public? No, if you'd made changes at all you'd have been sued by a company with extremely deep pockets. Even if it wasn't Microsoft, no proprietary vendor is going to let you make changes to their proprietary application without charging you obscene amounts of money.
Note also that you are only required to give up the source to your changes if you distribute the modified application outside your organization. Again, this is something you couldn't even do with a proprietary piece of software. Chances are, if proprietary software was even a possible choice when this decision was made, you haven't been doing this. So you aren't required to do anything.
So the only argument left is whether you should give back your changes. Sounds to me that the author of this article already knows full well that making a moral argument about what the company "ought" to do will get him laughed out of the room. So the arguments he's seeking are reasons why it's in the company's best interests to release its code.
Now you can look at the situation the other way round: Hey, look, because this application is Open Source we have the opportunity to do something that's in our best interests that we never would have had the opportunity to do with proprietary software.
Of course, I'm presupposing that releasing changes really is in the company's best interests. That's a separate argument (although I believe it's a pretty easy one to win:) ). But if it isn't, obviously, the company simply won't do it. So your claim that somehow advocating the use of Open Source software was somehow misleading is wrong. They got a bunch of benefits already through the use of the software. What the poster wants to do now is get another bunch of benefits (reduced maintenance cost is probably the big one) through releasing changes back to the original authors.
(Also note that the original post never said that the software in question was GPL. The idea of giving back source is just as tempting for BSD and X11 licensed projects.)
Perhaps my estimation of what's BIG has been tainted by the long line of disappointingly tiny steps that Sun has taken in the past:)
It's fair to say that Java is my home ground; I've used it in my day job for the past 2 years and also made some minor contributions to various attempts at replicating it in true Open Source. Most of what I've been involved in has been server-side; widespread desktop usage would be great, IMHO, but that still seems a long way off from where I stand. For technical reasons (crappy toolkit) as well as political ones.
I agree that true Open Source should be considered the ultimate goal. I sympathize with those that won't consider using Java unless it is Open Source - sometimes I feel bad myself for using it in its current state of non-openness (and no, it's not "no longer" - Java is more open now than it ever was (except perhaps for the trademark, which is irrelevant really), but still far from being open enough).
So having said all that, let me qualify my use of "BIG" in capital letters. I think this is a BIG step towards the ultimate goal of true Open Source for Java. As I said in my original post, what Sun does now will determine whether they continue after this one big step to make the other 4 or 5 similar-sized steps to actually releasing the JDK as Open Source.
I understand, but disagree with, your point about "just two players" not being enough. The unfortunate situation with Java today is that by definition, one player is enough - if that player is Sun. Nobody else can make any difference at all. So the significance of this step is that Sun is one of the parties to it - which implies that it really will make a difference. Until the magical point of true Open Source is reached, the only steps that matter to Java are those made by Sun. After that, the benefits of Open Source start applying and everybody gets a say.
I don't know which version they're using for the CompuServe release - AIUI the AOL beta test used a very old version, not much if any more recent than NS6.2. So the following may not apply to the CompuServe release.
But...
they sound only incrementally better than the official Netscape releases
I wouldn't quite say that's true. I'd say, rather, that each Mozilla milestone release is incrementally better than the last. NS6.2 remains based on 0.9.4 (technically 0.9.4.1 or some such but we won't go into that). 0.9.5 was incrementally better. 0.9.6 was incrementally better again. Ditto 0.9.7, 0.9.8 and 0.9.9. At some point, that loose change starts adding up into real money.
I used each version in sequence, so I can't judge the total magnitude of the improvement I've seen since 0.9.4. And each milestone does, to be fair, introduce its own share of minor annoyances. The likelihood of finding one or two unfinished or regressed features is higher in current mozilla milestones (hopefully 1.0 will be the exception to that... or maybe the difference will come in the 1.0.1 deliberately-bugfix-only release).
Ok... but do you or anyone else in here have any opinions related to the topic of the story?:)
(Or, for that matter, the substance of my post?)
If not, then I'm still having a discussion all by myself - at least, inasmuch as it relates to the topic of the story, which is what I would have liked to discuss.
Still, meaningless meta-discussion is better than no discussion at all, I guess;)
I hate when interesting stories get posted on slashboxes, because that means there's pretty much guaranteed to be no discussion at all.
Oh well... I can still have a discussion all by myself in here:)
This is good news and a BIG step in the right direction. Where we go from here seems to depend on whether Sun work in good faith or not. If they do the bare minimum to meet their side of the agreement, or drag their feet, then nothing will really change.
If on the other hand they take the agreement as a starting point and push forward with it agressively, this could be the start of a quiet revolution in the Java world. Getting more and more JSRs with Open Source reference implementations will start a process where Sun recognizes the positive PR and positive impact on the development process (the success of Tomcat itself has probably opened a few eyes inside Sun to the possibility of this) and might lead, eventually, to the opening of the entire JDK.
Making the JDK itself open source would pave the way for its inclusion in all major Linux distributions (including debian!) and for vast amounts of open source bug-fixing talent to be set to work. Unlike the initial release of OpenOffice or Mozilla, the JDK isn't in "that bad" of a state today, codewise, as far as I can tell, so the ramp-up period to widespread community involvement could be much quicker (although there are always the social barriers to break down).
And suddenly things like using Tomcat over say PHP or mod_perl wouldn't make you a second-class citizen in the open source world:)
And as it happens, the news.com.com article actually confirms that this is the case. "The OQO uses the same tiny hard drive from Toshiba that Apple Computer incorporates into the latest iPod."
I don't think it's much of a stretch to say that.NET is in many ways a multilingual Java (with a few other improvements).
That's approximately my opinion too. There are slight advantages to both (Java is more cross-platform and more mature,.NET has more languages and was able to learn from a few of Java's mistakes) but none that are terribly compelling.
In my opinion the "winner" out of.NET and Java (for my own needs, not necessarily the market's - but maybe that too) will be whichever gets more Open faster. Sun still have an iron grip on the Java implementation, and MS on the.NET one. Open Source Java implementations languished a bit, but ORP and Classpath and the newly-revived Kaffe are looking promising. And Mono is making amazing strides on.NET. Either one could win the battle for *my* heart in an instant by Open Sourcing their implementation.
Technically speaking though, there's really not a whole lot of difference. And yes, they're *both* pretty sweet:)
The problem is that *every* browser, from IE1 and NS1 up, will simply ignore CSS features they don't understand, which was part of the design of CSS and allows pages to degrade gracefully. Every browser, that is, *except* for Netscape 4.
Every other browser will either honor or ignore your font color selections, either of which looks okay. Netscape 4 will honor your font color selections only on the table row where the text is longest, in some circumstances, which invariably looks awful. Setting certain vertical-alignment properties on images will either work or not work in other browsers; in Netscape 4 it will randomly reorder your images. And so on.
For every other browser ever made, you can safely use any feature of CSS and get something which will look *okay* - either your stylesheet will be honored or not. With Netscape 4, if you happen to use the wrong part of CSS, your page will be completely unreadable.
You might not agree with the previous poster's position, but it is a logical approach. If Netscape 4 is remotely widely used among your site's visitors, it's really the only approach.
NO, they are NOT. They are MSIL code, native code, and metadata packaged in a PE/COFF file with an exe extension.
That's true. But your previous comments implied that they were directly x86 machine code, not MSIL code (note that the "I" in MSIL stands for "intermediate" - that is, not machine code).
Let's define some parallels so that we're working from the same set of definitions:
With these definitions, of course.NET executables don't run on a J(ava)VM, but they run on the CLR which is the.NET equivalent of a JVM. Both the JVM and the CLR can be implemented in a couple of ways: one is JIT (compile each class to native x86/whatever code as it's loaded), another is as an interpreter (JDK1.0 and Mono's "mint" do this) and another is ITC (gcj and TowerJ do this for java, although Sun don't like it much).
Likewise, arguing about the word "bytecode" is semantics. MSIL parallels java bytecode almost opcode for opcode (although obviously with different syntax for the opcodes, and a few enhancements to address real or perceived problems with java bytecode).
With regard to secret Intel optimizations - Mono won't take advantage of those anyway, even if MS's CLR does. So your original point about having cross-platform access to SSE2 instructions still fails, despite your elaboration.
Having said all that, this post did make a lot more sense than the previous one. So I'm sorry if I treated you as, well, "maliciously ignorant" as opposed to simply unaware of a few pertinent facts.
I still say you shouldn't argue things until you're sure you know them, though.
By the same distinction, what is the current viewpoint of running Java code under Linux with the binfmt_misc module enabled? Do we view the Java as machine code, because the kernel is running it (even though its just calling the interpreter), or do we view the kernel as having a JVM "built in"?
Well, do you view shell scripts as machine code just because putting #!/bin/bash as the first line lets the kernel execute them natively? binfmt_misc is just the same as #! except for file formats that don't have the freedom to start with a #! line.
My point is that what you call it is up to you, but that what you call it should not be the basis of your argument for or against it. What MS does with the CLR is almost exactly analagous to executing JAR files with binfmt_misc. So on that aspect of.NET versus Java, neither clearly wins.
The sad thing is that NOBODY, across several subthreads, has picked up on one simple thing: This assertion is blatantly untrue..NET executables *are* bytecode, they're just bytecode packaged in a.exe wrapper that Windows operating systems know how to pass to the proper JIT compiler.
If you're going to advocate.NET, you ought to do it on the basis of actual facts.
If you still want to claim that.NET executables don't need a JIT or a JVM, take a look at http://www.go-mono.com/runtime.html . Specifically the first sentence which talks about a "byte code interpreter", and the bit that says "We currently have two runtimes: mono: the Just In Time compiler [... and] mint: the Mono interpreter."
Your comments about taking advantage of the X86 SSE2 instructions are also bogus. If Microsoft's.NET compiler has an optimization that will allow certain bytecode sequences to be JITed into SSE2 instructions on x86 processors, that's great! But don't try to imply that a Java VM couldn't implement exactly those same optimizations, because it could.
.NET (at least the CLR part of it, and if you don't know what CLR refers to you *really* shouldn't be advocating it) *is* a good idea. But it's a good idea for the *same* reasons that Java is - with almost exactly the same tradeoffs except that CLR gives slightly better multi-language capability (only slightly!) and Java gives slightly better cross-platform capability (again, only slightly! - at least if mono keeps up the momentum it has now).
It's always sad to see good ideas advocated by people who clearly don't have a clue what they're talking about. It gives *all* advocates of the idea a bad name.
Re:One thing that's starting to annoy me about deb
on
KDE 3.0 is Out
·
· Score: 2
In my experience, if you run sid, it usually takes less than a week to get a new release of something. The main exception is XFree86, because it's such a complex package and completely vital to almost every system, and so the maintainer is (rightly, IMHO) very change-averse.
I would be surprised if it takes more than a week for KDE3 to hit sid. If you want the increased stability of woody, you have to wait a little bit longer, but you don't get days like today where python is completely broken.
I'm pretty sure there have been aptable repositories for KDE3 provided *by the Debian KDE maintainers* for some weeks already (as a GNOME user myself, I wouldn't know for sure, but I've seen it mentioned). So the bulk of the work is done.
The GNOME2 betas are a little harder to play with, because unless you want to destabilize your existing GNOME setup, you can't parallel-install GNOME2. Nonetheless, most of the beta is packaged, if you're willing to take the risk of installing it.
If *I* was slashdot and planning on implementing a major and obviously controversial new policy, I don't think I'd pick April 1st as the day to roll it out;)
The question will be, how many poor suckers will swallow the bait:)
I'm citing RMS's stated opinion on this, but it happens to be one I agree with (actually I don't usually really care about what license anything's under so long as it's truly Free/OpenSource according to the respective definitions).
In the case of Ogg, this is a file format we are talking about. The value of a file format isn't proportional to the quality of the format, but to the amount of content available in it. The amount of content available will be determined by how many people use it.
Freedom to view content in a file format that nobody uses is not much use, so in this kind of situation insisting on preserving freedom to the detriment of wide usage doesn't gain anything. Therefore, in this situation it's better to take the hit of getting our (that is, the free software community's) code used in evil proprietary software than to insist on complete freedom and have many corps not use the format.
RMS is dogmatic about many things, but he is willing to be pragmatic in certain cases. Generally his rule seems to be that he'll make pragmatic decisions if they (1) don't compromize his ethics, and (2) result in a *net gain* of freedom for software users.
Do you see the contradiction in saying you never trust anyone except Ogg, and then insisting on GPL only? Hint: Ogg was originally LGPL, and is now X11 - even *less* GPL (and in Ogg's case, RMS agreed this was a good move, because of the network effect needed to get good Ogg adoption).
I was never really involved in the DivX;) scene, but by my understanding the DivX license was never *really* open source. If it had been, they *couldn't* "take it proprietary", just take *future versions* proprietary (in which case a fork would take place and other interested coders could keep the open source version going). Since this didn't happen, I'm assuming that the license wasn't really open source.
It should be noted that VP3 has been under an "allegedly" open source license for ages, but it was one of these SCSL- or BitKeeper-style things that requires you only use the code for developing codecs compatible with the VP3 spec. This made it not truly open source, and left me at least very unenthusiastic about it (at that point they *could* have made it proprietary, effectively, through messing with the "official" specs often enough to make following them impossible). Now it's under a truly free license (or at least once such a release is made) there's no reason to be dubious anymore.
This is "extremely sensitive data" and you're ensuring its security by... asking the browser not to display it???
(I could be misunderstanding your situation, but your original post was about making things invisible and now you're talking about sensitive data. Sorry if I put 2 and 2 together and got 5)
If I *didn't* misunderstand you, though, you've got WAY more serious issues than "Mozilla's broken". Like "view source". And "wget" (with a spoofed useragent if necessary). And "disable javascript and css". And "display: block !important" in a user stylesheet. All of these are *standard* ways that a user could completely bypass your "security", and most of them apply to IE just as much as to Mozilla.
Number 1 rule of security is NEVER TRUST THE CLIENT. Even if you think you know what the client is. You can never guarantee that the http request claiming an IE useragent isn't really a spoofing mozilla browser or a deliberately malicious wget command.
I seriously hope I'm wrong about what you are requesting here.
It's pretty easy to understand. Mozilla is getting close to 1.0, so AOL started testing it.
Correlation doesn't imply causation - but sometimes it's to do with causation in the *other direction*:)
BTW, the plan to have 1.0 after 0.9.9 has been the intention for *ages*. Personally there are a few issues that I'd still like to see fixed that probably won't be for 1.0, but it'll certainly be nice to not have to qualify everything with "of course, it's only a pre-release".
3389. Found in the man page for rdesktop - http://www.rdesktop.org/ or apt-get install rdesktop.
Wrt the original poster's question, I suggest a combination of ssh and putting your email on an IMAP server. That way all your email is kept server-side but your email client happily manipulates it as if it's local. Any decent email client supports IMAP. Of course, if you're not on *nix then the server side of the equation might be interesting...
Customers? Bah! Dirty Theives and Pirates, Arrest 'em! Copyright Be Damned, Totally Prevent Access! Congress Bought, Democracy Totally Perverted. Alright! Cast Blame on Decent Tools with Potential for Abuse. Campaign to Ban Digital Technology that Plays Anything. Campaign to Ban Digital Technology that People can Access. Corporate-Bought Decision To Prohibit Academia. Corporate Behemoths Disallow Tinkering, Plan Arrests.
Yeah, and this one comfortably looks like it could hit #1:(
Love couldn't beat out terrorism, but bitching and moaning about having to pay for something - *that* beats terrorism.
It's sad;)
Stuart.
Re:Please do correct me if I'm wrong, but
on
How to Save PGP
·
· Score: 3, Interesting
Encryption (S/MIME) in Netscape and outlook is it's own worst enemy, because of the requirement to submit your personal information to a "trusted" third party (ie, a corporation - who many of those smart enough to know that encryption isn't a good idea won't trust at all) and then rely on the same "trusted" party to verify that everyone else in the world is who they say they are.
There's nothing wrong with S/MIME as a message format, but the implementations fall far short of what (as I understand it) PGP does: allowing you to generate your key without anyone having to verify it, and then YOU choose to ask specific people to verify it too. If you try to do this with any S/MIME client that I know of, it will claim that the certificate is untrustworthy because Friendly Trusted Company, Inc hasn't signed for it. PGP will try to find a way through the "web of trust" via a chain of people who all trust each other, from you to the person in question.
If someone were to integrate the S/MIME message format with PGP-style keysigning and webs of trust, and persuade the email clients to stop insisting that only TrustedCompany signed keys are trustworthy, I suspect that encryption would be a lot more widely used...
Slashdot Mirror
Fifthly, the poster specifically said that lawyers would need to be consulted before code could be released. Lawyers are at least as expensive as coders, so your "Net loss: $0" is certainly not accurate.
How about this scenario. The figures could go either way, but it's important to note which figures are one-time and which are recurring...
Releasing code:
- Lawyer time ($nnn, one-time)
- Programmer time to work with external maintainer to get patches accepted into the external source tree ($mmm, one-time, probably not a terribly large amount of time)
Keeping code internal:
- No lawyer time ($0)
- No up-front programmer time ($0)
- Programmer time to re-integrate local changes into new externally-released version of program ($ppp, recurring, and probably much larger than $mmm, at least).
Now, depending on the lawyer cost, a single upgrade might or might not work out cheaper if the code is kept internally. But eventually a recurring cost is guaranteed to come out greater than any one-time cost. This is even more true if the legal work can be done once to cover all future open source contributions, so that the lawyer cost can be split across multiple applications.
What a lot of managers don't realize is that maintaining a fork of a program's source code is expensive. As your codebase diverges from the external one, important bugfixes applied to the latter become harder and harder to apply to your local copy, taking more and more programmer time to keep up. Paying a little more up front in that situation is just good sense.
Beyond that, since the implication of the article is that these are changes to existing projects, tell them that keeping a locally-modified version will require substantial maintenance just to upgrade to each new release. In other (buzz)words, emphasize the large recurring maintenance cost of the status quo.
:)
Paying once for the time spent in politics with the external maintainers to get the patches integrated will probably be less than the cost of upgrading to a new external release even once.
The other thing to ask is whether the company expected to make any money directly off the code changes in the first place. This may be "Corporate IP" that has a theoretical monetary "value", but in most cases the company has no plans on actually realizing that value. Point out that you aren't really giving away any value if you weren't planning on getting any dollars out of that value in the first place.
They might respond to that with "well, we should go and figure out how to realize that value, then". If they do, you might want to actually go through the motions of exploring how to extract the value. It should be fairly obvious without biasing your results that there really isn't any way to profitably extract value from a few random patches to an open source project. Ask if they really want to get into the software-selling business. Figure out how much it would cost to create the infrastructure and legal red tape to do this (count people's hours at billable rate if you like), and guesstimate an optimistic figure for how much you could sell the patches for, and how many copies you would sell. Present all of this in a nice presentation showing how you'd actually lose a substantial amount if you tried to do it.
Given all this background, you can present the three alternatives: Keep the code private (large recurring maintenance cost), sell the code (certainly a negative profit), or give the code away (small one-time integration cost). The desired course of action should be obvious
This all depends on what you are comparing to. If the alternative to the Open Source software was proprietary software, your argument falls apart.
:) ). But if it isn't, obviously, the company simply won't do it. So your claim that somehow advocating the use of Open Source software was somehow misleading is wrong. They got a bunch of benefits already through the use of the software. What the poster wants to do now is get another bunch of benefits (reduced maintenance cost is probably the big one) through releasing changes back to the original authors.
Suppose that the alternative to GNU SurfWriter was Microsoft Surf. Would you have had to release your changes ("IP") to the public? No, if you'd made changes at all you'd have been sued by a company with extremely deep pockets. Even if it wasn't Microsoft, no proprietary vendor is going to let you make changes to their proprietary application without charging you obscene amounts of money.
Note also that you are only required to give up the source to your changes if you distribute the modified application outside your organization. Again, this is something you couldn't even do with a proprietary piece of software. Chances are, if proprietary software was even a possible choice when this decision was made, you haven't been doing this. So you aren't required to do anything.
So the only argument left is whether you should give back your changes. Sounds to me that the author of this article already knows full well that making a moral argument about what the company "ought" to do will get him laughed out of the room. So the arguments he's seeking are reasons why it's in the company's best interests to release its code.
Now you can look at the situation the other way round: Hey, look, because this application is Open Source we have the opportunity to do something that's in our best interests that we never would have had the opportunity to do with proprietary software.
Of course, I'm presupposing that releasing changes really is in the company's best interests. That's a separate argument (although I believe it's a pretty easy one to win
(Also note that the original post never said that the software in question was GPL. The idea of giving back source is just as tempting for BSD and X11 licensed projects.)
Perhaps my estimation of what's BIG has been tainted by the long line of disappointingly tiny steps that Sun has taken in the past :)
It's fair to say that Java is my home ground; I've used it in my day job for the past 2 years and also made some minor contributions to various attempts at replicating it in true Open Source. Most of what I've been involved in has been server-side; widespread desktop usage would be great, IMHO, but that still seems a long way off from where I stand. For technical reasons (crappy toolkit) as well as political ones.
I agree that true Open Source should be considered the ultimate goal. I sympathize with those that won't consider using Java unless it is Open Source - sometimes I feel bad myself for using it in its current state of non-openness (and no, it's not "no longer" - Java is more open now than it ever was (except perhaps for the trademark, which is irrelevant really), but still far from being open enough).
So having said all that, let me qualify my use of "BIG" in capital letters. I think this is a BIG step towards the ultimate goal of true Open Source for Java. As I said in my original post, what Sun does now will determine whether they continue after this one big step to make the other 4 or 5 similar-sized steps to actually releasing the JDK as Open Source.
I understand, but disagree with, your point about "just two players" not being enough. The unfortunate situation with Java today is that by definition, one player is enough - if that player is Sun. Nobody else can make any difference at all. So the significance of this step is that Sun is one of the parties to it - which implies that it really will make a difference. Until the magical point of true Open Source is reached, the only steps that matter to Java are those made by Sun. After that, the benefits of Open Source start applying and everybody gets a say.
Stuart.
I don't know which version they're using for the CompuServe release - AIUI the AOL beta test used a very old version, not much if any more recent than NS6.2. So the following may not apply to the CompuServe release.
But...
they sound only incrementally better than the official Netscape releases
I wouldn't quite say that's true. I'd say, rather, that each Mozilla milestone release is incrementally better than the last. NS6.2 remains based on 0.9.4 (technically 0.9.4.1 or some such but we won't go into that). 0.9.5 was incrementally better. 0.9.6 was incrementally better again. Ditto 0.9.7, 0.9.8 and 0.9.9. At some point, that loose change starts adding up into real money.
I used each version in sequence, so I can't judge the total magnitude of the improvement I've seen since 0.9.4. And each milestone does, to be fair, introduce its own share of minor annoyances. The likelihood of finding one or two unfinished or regressed features is higher in current mozilla milestones (hopefully 1.0 will be the exception to that... or maybe the difference will come in the 1.0.1 deliberately-bugfix-only release).
But it can't hurt to try it, can it?
you're not the only one in here you know! :o)
:)
;)
Ok... but do you or anyone else in here have any opinions related to the topic of the story?
(Or, for that matter, the substance of my post?)
If not, then I'm still having a discussion all by myself - at least, inasmuch as it relates to the topic of the story, which is what I would have liked to discuss.
Still, meaningless meta-discussion is better than no discussion at all, I guess
Stuart.
I hate when interesting stories get posted on slashboxes, because that means there's pretty much guaranteed to be no discussion at all.
:)
:)
Oh well... I can still have a discussion all by myself in here
This is good news and a BIG step in the right direction. Where we go from here seems to depend on whether Sun work in good faith or not. If they do the bare minimum to meet their side of the agreement, or drag their feet, then nothing will really change.
If on the other hand they take the agreement as a starting point and push forward with it agressively, this could be the start of a quiet revolution in the Java world. Getting more and more JSRs with Open Source reference implementations will start a process where Sun recognizes the positive PR and positive impact on the development process (the success of Tomcat itself has probably opened a few eyes inside Sun to the possibility of this) and might lead, eventually, to the opening of the entire JDK.
Making the JDK itself open source would pave the way for its inclusion in all major Linux distributions (including debian!) and for vast amounts of open source bug-fixing talent to be set to work. Unlike the initial release of OpenOffice or Mozilla, the JDK isn't in "that bad" of a state today, codewise, as far as I can tell, so the ramp-up period to widespread community involvement could be much quicker (although there are always the social barriers to break down).
And suddenly things like using Tomcat over say PHP or mod_perl wouldn't make you a second-class citizen in the open source world
A good suggestion.
And as it happens, the news.com.com article actually confirms that this is the case. "The OQO uses the same tiny hard drive from Toshiba that Apple Computer incorporates into the latest iPod."
there aren't any Village People songs about the DMCA
Really?
I don't think it's much of a stretch to say that .NET is in many ways a multilingual Java (with a few other improvements).
.NET has more languages and was able to learn from a few of Java's mistakes) but none that are terribly compelling.
.NET and Java (for my own needs, not necessarily the market's - but maybe that too) will be whichever gets more Open faster. Sun still have an iron grip on the Java implementation, and MS on the .NET one. Open Source Java implementations languished a bit, but ORP and Classpath and the newly-revived Kaffe are looking promising. And Mono is making amazing strides on .NET. Either one could win the battle for *my* heart in an instant by Open Sourcing their implementation.
:)
That's approximately my opinion too. There are slight advantages to both (Java is more cross-platform and more mature,
In my opinion the "winner" out of
Technically speaking though, there's really not a whole lot of difference. And yes, they're *both* pretty sweet
Stuart.
The problem is that *every* browser, from IE1 and NS1 up, will simply ignore CSS features they don't understand, which was part of the design of CSS and allows pages to degrade gracefully. Every browser, that is, *except* for Netscape 4.
Every other browser will either honor or ignore your font color selections, either of which looks okay. Netscape 4 will honor your font color selections only on the table row where the text is longest, in some circumstances, which invariably looks awful. Setting certain vertical-alignment properties on images will either work or not work in other browsers; in Netscape 4 it will randomly reorder your images. And so on.
For every other browser ever made, you can safely use any feature of CSS and get something which will look *okay* - either your stylesheet will be honored or not. With Netscape 4, if you happen to use the wrong part of CSS, your page will be completely unreadable.
You might not agree with the previous poster's position, but it is a logical approach. If Netscape 4 is remotely widely used among your site's visitors, it's really the only approach.
Stuart.
NO, they are NOT. They are MSIL code, native code, and metadata packaged in a PE/COFF file with an exe extension.
.NET executables don't run on a J(ava)VM, but they run on the CLR which is the .NET equivalent of a JVM. Both the JVM and the CLR can be implemented in a couple of ways: one is JIT (compile each class to native x86/whatever code as it's loaded), another is as an interpreter (JDK1.0 and Mono's "mint" do this) and another is ITC (gcj and TowerJ do this for java, although Sun don't like it much).
.NET versus Java, neither clearly wins.
That's true. But your previous comments implied that they were directly x86 machine code, not MSIL code (note that the "I" in MSIL stands for "intermediate" - that is, not machine code).
Let's define some parallels so that we're working from the same set of definitions:
MSIL (Microsoft Intermediate Language) <=> Java Bytecode
CLR (Common Language Runtime) <=> JVM (Java Virtual Machine)
ITC (Install-Time Codegen) <=> Native compilation
With these definitions, of course
Likewise, arguing about the word "bytecode" is semantics. MSIL parallels java bytecode almost opcode for opcode (although obviously with different syntax for the opcodes, and a few enhancements to address real or perceived problems with java bytecode).
With regard to secret Intel optimizations - Mono won't take advantage of those anyway, even if MS's CLR does. So your original point about having cross-platform access to SSE2 instructions still fails, despite your elaboration.
Having said all that, this post did make a lot more sense than the previous one. So I'm sorry if I treated you as, well, "maliciously ignorant" as opposed to simply unaware of a few pertinent facts.
I still say you shouldn't argue things until you're sure you know them, though.
By the same distinction, what is the current viewpoint of running Java code under Linux with the binfmt_misc module enabled? Do we view the Java as machine code, because the kernel is running it (even though its just calling the interpreter), or do we view the kernel as having a JVM "built in"?
Well, do you view shell scripts as machine code just because putting #!/bin/bash as the first line lets the kernel execute them natively? binfmt_misc is just the same as #! except for file formats that don't have the freedom to start with a #! line.
My point is that what you call it is up to you, but that what you call it should not be the basis of your argument for or against it. What MS does with the CLR is almost exactly analagous to executing JAR files with binfmt_misc. So on that aspect of
The sad thing is that NOBODY, across several subthreads, has picked up on one simple thing: This assertion is blatantly untrue. .NET executables *are* bytecode, they're just bytecode packaged in a .exe wrapper that Windows operating systems know how to pass to the proper JIT compiler.
.NET, you ought to do it on the basis of actual facts.
.NET executables don't need a JIT or a JVM, take a look at http://www.go-mono.com/runtime.html . Specifically the first sentence which talks about a "byte code interpreter", and the bit that says "We currently have two runtimes: mono: the Just In Time compiler [... and] mint: the Mono interpreter."
.NET compiler has an optimization that will allow certain bytecode sequences to be JITed into SSE2 instructions on x86 processors, that's great! But don't try to imply that a Java VM couldn't implement exactly those same optimizations, because it could.
If you're going to advocate
If you still want to claim that
Your comments about taking advantage of the X86 SSE2 instructions are also bogus. If Microsoft's
.NET (at least the CLR part of it, and if you don't know what CLR refers to you *really* shouldn't be advocating it) *is* a good idea. But it's a good idea for the *same* reasons that Java is - with almost exactly the same tradeoffs except that CLR gives slightly better multi-language capability (only slightly!) and Java gives slightly better cross-platform capability (again, only slightly! - at least if mono keeps up the momentum it has now).
It's always sad to see good ideas advocated by people who clearly don't have a clue what they're talking about. It gives *all* advocates of the idea a bad name.
In my experience, if you run sid, it usually takes less than a week to get a new release of something. The main exception is XFree86, because it's such a complex package and completely vital to almost every system, and so the maintainer is (rightly, IMHO) very change-averse.
I would be surprised if it takes more than a week for KDE3 to hit sid. If you want the increased stability of woody, you have to wait a little bit longer, but you don't get days like today where python is completely broken.
I'm pretty sure there have been aptable repositories for KDE3 provided *by the Debian KDE maintainers* for some weeks already (as a GNOME user myself, I wouldn't know for sure, but I've seen it mentioned). So the bulk of the work is done.
The GNOME2 betas are a little harder to play with, because unless you want to destabilize your existing GNOME setup, you can't parallel-install GNOME2. Nonetheless, most of the beta is packaged, if you're willing to take the risk of installing it.
If *I* was slashdot and planning on implementing a major and obviously controversial new policy, I don't think I'd pick April 1st as the day to roll it out ;)
:)
The question will be, how many poor suckers will swallow the bait
Stuart.
I'm citing RMS's stated opinion on this, but it happens to be one I agree with (actually I don't usually really care about what license anything's under so long as it's truly Free/OpenSource according to the respective definitions).
In the case of Ogg, this is a file format we are talking about. The value of a file format isn't proportional to the quality of the format, but to the amount of content available in it. The amount of content available will be determined by how many people use it.
Freedom to view content in a file format that nobody uses is not much use, so in this kind of situation insisting on preserving freedom to the detriment of wide usage doesn't gain anything. Therefore, in this situation it's better to take the hit of getting our (that is, the free software community's) code used in evil proprietary software than to insist on complete freedom and have many corps not use the format.
RMS is dogmatic about many things, but he is willing to be pragmatic in certain cases. Generally his rule seems to be that he'll make pragmatic decisions if they (1) don't compromize his ethics, and (2) result in a *net gain* of freedom for software users.
Stuart.
Do you see the contradiction in saying you never trust anyone except Ogg, and then insisting on GPL only? Hint: Ogg was originally LGPL, and is now X11 - even *less* GPL (and in Ogg's case, RMS agreed this was a good move, because of the network effect needed to get good Ogg adoption).
I was never really involved in the DivX;) scene, but by my understanding the DivX license was never *really* open source. If it had been, they *couldn't* "take it proprietary", just take *future versions* proprietary (in which case a fork would take place and other interested coders could keep the open source version going). Since this didn't happen, I'm assuming that the license wasn't really open source.
It should be noted that VP3 has been under an "allegedly" open source license for ages, but it was one of these SCSL- or BitKeeper-style things that requires you only use the code for developing codecs compatible with the VP3 spec. This made it not truly open source, and left me at least very unenthusiastic about it (at that point they *could* have made it proprietary, effectively, through messing with the "official" specs often enough to make following them impossible). Now it's under a truly free license (or at least once such a release is made) there's no reason to be dubious anymore.
Stuart.
Hold on a second.
This is "extremely sensitive data" and you're ensuring its security by... asking the browser not to display it???
(I could be misunderstanding your situation, but your original post was about making things invisible and now you're talking about sensitive data. Sorry if I put 2 and 2 together and got 5)
If I *didn't* misunderstand you, though, you've got WAY more serious issues than "Mozilla's broken". Like "view source". And "wget" (with a spoofed useragent if necessary). And "disable javascript and css". And "display: block !important" in a user stylesheet. All of these are *standard* ways that a user could completely bypass your "security", and most of them apply to IE just as much as to Mozilla.
Number 1 rule of security is NEVER TRUST THE CLIENT. Even if you think you know what the client is. You can never guarantee that the http request claiming an IE useragent isn't really a spoofing mozilla browser or a deliberately malicious wget command.
I seriously hope I'm wrong about what you are requesting here.
It's pretty easy to understand. Mozilla is getting close to 1.0, so AOL started testing it.
:)
Correlation doesn't imply causation - but sometimes it's to do with causation in the *other direction*
BTW, the plan to have 1.0 after 0.9.9 has been the intention for *ages*. Personally there are a few issues that I'd still like to see fixed that probably won't be for 1.0, but it'll certainly be nice to not have to qualify everything with "of course, it's only a pre-release".
Stuart.
3389. Found in the man page for rdesktop - http://www.rdesktop.org/ or apt-get install rdesktop.
Wrt the original poster's question, I suggest a combination of ssh and putting your email on an IMAP server. That way all your email is kept server-side but your email client happily manipulates it as if it's local. Any decent email client supports IMAP. Of course, if you're not on *nix then the server side of the equation might be interesting...
Customers? Bah! Dirty Theives and Pirates, Arrest 'em!
Copyright Be Damned, Totally Prevent Access!
Congress Bought, Democracy Totally Perverted. Alright!
Cast Blame on Decent Tools with Potential for Abuse.
Campaign to Ban Digital Technology that Plays Anything.
Campaign to Ban Digital Technology that People can Access.
Corporate-Bought Decision To Prohibit Academia.
Corporate Behemoths Disallow Tinkering, Plan Arrests.
Campaign to Ban Digital Technology that People can Access
or myfy.com, a domain registered to a subsidiary of ING insurance group.
This has got more comments than Taco's proposal!
:(
;)
Yeah, and this one comfortably looks like it could hit #1
Love couldn't beat out terrorism, but bitching and moaning about having to pay for something - *that* beats terrorism.
It's sad
Stuart.
Encryption (S/MIME) in Netscape and outlook is it's own worst enemy, because of the requirement to submit your personal information to a "trusted" third party (ie, a corporation - who many of those smart enough to know that encryption isn't a good idea won't trust at all) and then rely on the same "trusted" party to verify that everyone else in the world is who they say they are.
There's nothing wrong with S/MIME as a message format, but the implementations fall far short of what (as I understand it) PGP does: allowing you to generate your key without anyone having to verify it, and then YOU choose to ask specific people to verify it too. If you try to do this with any S/MIME client that I know of, it will claim that the certificate is untrustworthy because Friendly Trusted Company, Inc hasn't signed for it. PGP will try to find a way through the "web of trust" via a chain of people who all trust each other, from you to the person in question.
If someone were to integrate the S/MIME message format with PGP-style keysigning and webs of trust, and persuade the email clients to stop insisting that only TrustedCompany signed keys are trustworthy, I suspect that encryption would be a lot more widely used...
Stuart.