Yet, the article states very clearly: "Microsoft said it would continue to appeal the Commission's landmark ruling".
The only thing they won't appeal is the court order to "immediately implement antitrust sanctions".
This only means they will not appeal the ruling that says "you need to implement this NOW", which is in fact a ruling to the appeal they made to the main sanctions (sorry for getting complicated).
Appealing this "NOW!" ruling would not make any difference for the "NOW!" part, and it will not make any difference for the damages Microsoft will claim for the main case. And as there are no extra damages to the NOW! part, there's nothing to do here - which is exactly what Yahoo says.
We use and support Debian in a commercial environment - a financial institution. They run a Websphere application. We have a chrooted environment for the WS stuff itself, just to be sure that we/could/ switch to a RH/SuSE/anything distro, should that be necessary. However, while testing the WS installation with a chrooted RH, we found out that once the RH updates were there, the WS wouldn't install anymore.
That's when we switched to Debian - our preferred distribution - for the chrooted environment as well. Installation went out of the box. Whenever we make support calls, we get good, helpful answers. We have never experienced the dreadful "sorry, we don't support version 1.2.3.4" answer and in fact, IBM seems to be quite serious about delivering quality software with quality support, instead of trying to hide behind a version number.
Looking at newer versions of WS, it gets even better: instead of "RH 1.2.3 / SuSE 4.5.6" they now just need "a x.y+ kernel and a p.q+ C library". That's how it should work, and that's how it works at IBM.
So, I would just go for Debian if that's your easiest way of supporting the software, because that's probably what counts here. (Telling IBM you run Debian counts, too:)
I'm going to patent "a method to patent methods" in Europe. Of course, as patenting business methods is currently void, this patent would not work - yet. But once the new legislation is there, I'd have a great patent! And, as NAI's anti-spam patent proves: there's no such thing as prior art in software and/or business methods. Great.
The filtering in Corel WP8 stopped working some 1.5 years after the initial release of WP8 for Linux. Corel then effectively dropped support. Read all about it:
o.sessink.nl/~valentyn/wp8fix/corel.html
I wrote a fix, see http://o.sessink.nl/~valentyn/wp8fix/, and I vowed never to buy Corel again. They stink.
Ping the host (with large IP) without IPsec, then activate IPsec and ping again. Now as you've seen, the 2.6 kernel accomodates to the new MTU size. The bad thing is that the 2.4 backport of the 2.6 IPsec doesn't do that, which results in "too large" messages but no traffic.
I've seen NFS mounts come to a grinding halt because of this.
My setup is special in the sense that a 2.6 machine in between runs two tunnels: one to my office, one to a WiFi host (with a 2.4 kernel). I haven't found time yet to test a setup where the workstation runs 2.6 as well.
I've been testing with 2.6 IPsec, but I'm not convinced that it's production ready. Especially the MTU handling gives me the creeps:
valentijn:~# ping -s 1435 host21
PING host21.wireless.palmgracht.nl (10.15.67.21): 1435 data bytes
ping: sendto: Message too long
ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
ping: sendto: Message too long
ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
Resetting the MTU on the network interface helps:
valentijn:~# ifconfig eth1 mtu 1400
valentijn:~# ping -s 1417 host21
PING host21.wireless.palmgracht.nl (10.15.67.21): 1417 data bytes
1425 bytes from 10.15.67.21: icmp_seq=0 ttl=64 time=93.0 ms
1425 bytes from 10.15.67.21: icmp_seq=1 ttl=64 time=78.2 ms
Then, resetting it to 1500 again does this: valentijn:~# ifconfig eth1 mtu 1500 valentijn:~# ping -s 1435 host21
PING host21.wireless.palmgracht.nl (10.15.67.21): 1435 data bytes
ping: sendto: Message too long
ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
1443 bytes from 10.15.67.21: icmp_seq=1 ttl=64 time=89.0 ms
So only the first packet is blocked, after that the kernel adjusts to the right MTU. And please note: this is internally, the first packet doesn't leave the machine.
I had no time to test further, but what I found so far doesn't encourage me a lot to use 2.6 IPsec in production.
Found an ATM here in Amsterdam, the Netherlands, last january. It still ran Windows NT. See picture(s) at http://o.sessink.nl/~valentyn/postbank/ (there's a single picture there, will try to upload more from my photo album)
I found this Changelog entry rather funny. Looooong story about stir4200 driver - then another commit that adds stir4200.c:
[IRDA]: Add stir4200 driver. After a long maturation, this is time to send you the latest
version of the stir4200 USB driver. Initially started by Paul Stewart,
modified by Martin Diehl and me, and later partially rewriten by
Stephen Hemminger. The hardware has many quirks. This is the first version that
work reliably at SIR and mostly work at FIR. We may never get optimal
operation from this hardware due to its pecularities, but at least its
now usable.
[IRDA]: Forgot to add stir4200.c in previous commit.
brings the 2.6 ipsec kernel stuff into a 2.4.21 kernel. Works perfectly.
No, it doesn't. 2.6 IPsec has all sorts of problems with MTU, and 2.4 with 2.6 backport doesn't even understand it's own behaviour. You'll end up with situations like this: valentijn:~# ping -s 1435 host21
PING host21.wireless.palmgracht.nl (10.15.67.21): 1435 data bytes
ping: sendto: Message too long
ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
ping: sendto: Message too long
ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
The 2.6 native IPsec does have some MTU issues as well, but I haven't had time to research them well enough. However, from what I've seen, I think that having a 2.6 machine routing between two tunnels will most likely give you a headache, as larger IP fragments will not come through and 2.6 doesn't cut them to adjust to the new 1442 MTU. Besides, the 2.6 IPsec implementation doesn't handle IPsec in combination with iptables too well as there's no well defined way the packets travel through the tables. Encryption is handled somewhere between OUTPUT and POSTROUTING, which, for example, eliminates the possibility to use NAT. IPsec 2.6 works, but only in theory, so to say.
Slightly off topic: yesterday someone said that Google ranks W3-compliant pages higher than non-W3 compliant pages. I'm still confused. Could this be true?
What went wrong with the US law system? Microsoft is finally in compliance with their anti-trust regulations, opening up API's and stuff, and now the FBI is investigating that?;-)
The Habeas mark is just a way of making money, it has nothing to do with opt-in or responsible e-mailing. I've tried to contact Habeas in the past about a company that used their mark, while they did not correctly verify their opt-in mailadresses. There was no reply (and IIRC, their web form didn't work at all at the time).
"You have been blocked from entering this site.
You have attempted an unknown attack on this site."
Imagine a beowulf cluster of these!
Yes, I know this is Slashdot. Yes I know.
Yet, the article states very clearly: "Microsoft said it would continue to appeal the Commission's landmark ruling".
The only thing they won't appeal is the court order to "immediately implement antitrust sanctions".
This only means they will not appeal the ruling that says "you need to implement this NOW", which is in fact a ruling to the appeal they made to the main sanctions (sorry for getting complicated).
Appealing this "NOW!" ruling would not make any difference for the "NOW!" part, and it will not make any difference for the damages Microsoft will claim for the main case. And as there are no extra damages to the NOW! part, there's nothing to do here - which is exactly what Yahoo says.
ACD Systems Digital Imaging? That's the photo editing package at www.acdsystems.com, right?
With tabbed browsing, you can! Easily!
Leaving the planet won't help. American jurisdiction is controlled by the NASA.
a^2 - a^2 = a^2 - a^2 :=: :=:
a ( a - a ) = (a + a) * (a - a)
a = a + a
substitute 1 for a: 1 = 2.
Stop slashdotting http://www.spreadfirefox.com/, help stop the stagnant web!
We're about to discover the Real World, and the only thing we don't know if it's run by mice or if it's a giant TV show we're in :)
We use and support Debian in a commercial environment - a financial institution. They run a Websphere application. /could/ switch to a RH/SuSE/anything distro, should that be necessary.
:)
We have a chrooted environment for the WS stuff itself, just to be sure that we
However, while testing the WS installation with a chrooted RH, we found out that once the RH updates were there, the WS wouldn't install anymore.
That's when we switched to Debian - our preferred distribution - for the chrooted environment as well. Installation went out of the box. Whenever we make support calls, we get good, helpful answers. We have never experienced the dreadful "sorry, we don't support version 1.2.3.4" answer and in fact, IBM seems to be quite serious about delivering quality software with quality support, instead of trying to hide behind a version number.
Looking at newer versions of WS, it gets even better: instead of "RH 1.2.3 / SuSE 4.5.6" they now just need "a x.y+ kernel and a p.q+ C library". That's how it should work, and that's how it works at IBM.
So, I would just go for Debian if that's your easiest way of supporting the software, because that's probably what counts here. (Telling IBM you run Debian counts, too
In shell scripting, you can get Hello World in 7 characters:
$ echo 'echo $0' > 'Hello, World!'
$ chmod +x 'Hello, World!'
I'm going to patent "a method to patent methods" in Europe. Of course, as patenting business methods is currently void, this patent would not work - yet. But once the new legislation is there, I'd have a great patent! And, as NAI's anti-spam patent proves: there's no such thing as prior art in software and/or business methods. Great.
The filtering in Corel WP8 stopped working some 1.5 years after the initial release of WP8 for Linux. Corel then effectively dropped support. Read all about it: o.sessink.nl/~valentyn/wp8fix/corel.html
I wrote a fix, see http://o.sessink.nl/~valentyn/wp8fix/, and I vowed never to buy Corel again. They stink.
Ping the host (with large IP) without IPsec, then activate IPsec and ping again. Now as you've seen, the 2.6 kernel accomodates to the new MTU size. The bad thing is that the 2.4 backport of the 2.6 IPsec doesn't do that, which results in "too large" messages but no traffic.
I've seen NFS mounts come to a grinding halt because of this.
My setup is special in the sense that a 2.6 machine in between runs two tunnels: one to my office, one to a WiFi host (with a 2.4 kernel). I haven't found time yet to test a setup where the workstation runs 2.6 as well.
I've been testing with 2.6 IPsec, but I'm not convinced that it's production ready. Especially the MTU handling gives me the creeps:
valentijn:~# ping -s 1435 host21
PING host21.wireless.palmgracht.nl (10.15.67.21): 1435 data bytes
ping: sendto: Message too long
ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
ping: sendto: Message too long
ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
Resetting the MTU on the network interface helps:
valentijn:~# ifconfig eth1 mtu 1400
valentijn:~# ping -s 1417 host21
PING host21.wireless.palmgracht.nl (10.15.67.21): 1417 data bytes
1425 bytes from 10.15.67.21: icmp_seq=0 ttl=64 time=93.0 ms
1425 bytes from 10.15.67.21: icmp_seq=1 ttl=64 time=78.2 ms
Then, resetting it to 1500 again does this:
valentijn:~# ifconfig eth1 mtu 1500
valentijn:~# ping -s 1435 host21
PING host21.wireless.palmgracht.nl (10.15.67.21): 1435 data bytes
ping: sendto: Message too long
ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
1443 bytes from 10.15.67.21: icmp_seq=1 ttl=64 time=89.0 ms
So only the first packet is blocked, after that the kernel adjusts to the right MTU. And please note: this is internally, the first packet doesn't leave the machine.
I had no time to test further, but what I found so far doesn't encourage me a lot to use 2.6 IPsec in production.
No way... so by buying Microsoftware, we supported the FSF?
Found an ATM here in Amsterdam, the Netherlands, last january. It still ran Windows NT. See picture(s) at http://o.sessink.nl/~valentyn/postbank/ (there's a single picture there, will try to upload more from my photo album)
I found this Changelog entry rather funny. Looooong story about stir4200 driver - then another commit that adds stir4200.c:
[IRDA]: Add stir4200 driver.
After a long maturation, this is time to send you the latest
version of the stir4200 USB driver. Initially started by Paul Stewart,
modified by Martin Diehl and me, and later partially rewriten by
Stephen Hemminger.
The hardware has many quirks. This is the first version that
work reliably at SIR and mostly work at FIR. We may never get optimal
operation from this hardware due to its pecularities, but at least its
now usable.
[IRDA]: Forgot to add stir4200.c in previous commit.
No, it doesn't. 2.6 IPsec has all sorts of problems with MTU, and 2.4 with 2.6 backport doesn't even understand it's own behaviour. You'll end up with situations like this:
valentijn:~# ping -s 1435 host21
PING host21.wireless.palmgracht.nl (10.15.67.21): 1435 data bytes
ping: sendto: Message too long
ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
ping: sendto: Message too long
ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
The 2.6 native IPsec does have some MTU issues as well, but I haven't had time to research them well enough. However, from what I've seen, I think that having a 2.6 machine routing between two tunnels will most likely give you a headache, as larger IP fragments will not come through and 2.6 doesn't cut them to adjust to the new 1442 MTU. Besides, the 2.6 IPsec implementation doesn't handle IPsec in combination with iptables too well as there's no well defined way the packets travel through the tables. Encryption is handled somewhere between OUTPUT and POSTROUTING, which, for example, eliminates the possibility to use NAT. IPsec 2.6 works, but only in theory, so to say.
Slightly off topic: yesterday someone said that Google ranks W3-compliant pages higher than non-W3 compliant pages. I'm still confused. Could this be true?
What went wrong with the US law system? Microsoft is finally in compliance with their anti-trust regulations, opening up API's and stuff, and now the FBI is investigating that? ;-)
Sorry for having to mention this, but we get spam from Shuttle Germany: ``If you don't want this kind of email, then please answer with "No Mail".''
I will never do business with Shuttle. Shuttle in Germany is a spam supporting company.
Oh come on. This is just their way of complying with the anti-trust regulations, opening up the API's and stuff. ;-)
Feisty Dunnart is a Google Whack! (But will probably not last for long :)
The Habeas mark is just a way of making money, it has nothing to do with opt-in or responsible e-mailing. I've tried to contact Habeas in the past about a company that used their mark, while they did not correctly verify their opt-in mailadresses. There was no reply (and IIRC, their web form didn't work at all at the time).