Getting anything onto a handset takes a very close relationship with the handset maker. That real estate is extremely limited and every bit is accounted for. I'd bet that MS is subsidizing their phone OS to gain traction and that's a dangerous gift for the handset makers to fall for. If MS does manage to capture a majority of the handset market, handset makers can expect them to raise prices and eat into their profit margins.
That said, Nokia is the big fish to contend with in handsets. Due to Symbian, MS won't get Nokia to buy in unless they can get everybody else to buy in first. MS has gotten Samsung, Siemens and now Motorola to at least try their OS. They've even gotten Ericsson to dabble in portions of it. Although they've yet to make quantifiable inroads, the relationships required to turn up the heat are well established and cannot be taken lightly by the remaining of the Big 8, namely Nokia, LGE, Panasonic, and NEC. Keep you eye on the Japanese handset market, they (not Europe or the Americas) dictate the direction of the handset market. If the Embedded Linux Consortium holds together, it could pose the single most significant barrier to the MS Smartphone ever gaining traction.
All the large phone makers (Nokia, Sony Ericsson, Motorola) have very consciously decided against using MS software
As much as I detest Microsoft, Motorola has made the terrible decision of putting out a single MS powered phone (for Orange SA in Europe). Motorola then proceeded to restate that they're firmly commited to Java on Linux for future phones. I know Orange is an MS pawn but it's still disappointing to see Motorola lending credence to it.
Re:.net is great if your already an MS shop
on
Java vs .NET
·
· Score: 1
Technically wrong, conceptually right. Object variables (not primitives like int / bool/etc) are passed by reference in Java. It's not a pointer in the sense that you can reassign it, it's a reference in the sense that you work on the same object that you passed into the method. These refences are fully under the control of the JVM (see garbage collection for more info). This is why it's extremely difficult to cause a Java program to seg fault. You essentially have to choke off it's resources to get it to bomb.
SGI will likely just ask for a postponement until the IBM case is settled, or, that failing, use stalling tactics until IBM is done eviscerating SCO. Notice how SCO has yet to see the light of a courtroom, lotsa talk, not much walk. SGI may not have buckets of cash but they're still a 10x bigger fish than SCO.
Re:Lies, statistics, and analysts
on
Java vs .NET
·
· Score: 1
You probably haven't heard but as of JCP 2.5, open source implementations of Java standards are officially
supported under the JCP. Thanks to the JCP, we haven't been living in Sun-land since October of last year.
Re:It's obvious
on
Java vs .NET
·
· Score: 4, Interesting
Sun's not a monopoly and don't make it sound like MS gave the entire.NET framework to the ECMA. Nope, just the C# langauge and the CLI, this would be like Sun turning over javac and java to the ECMA but keeping a grip on anything beyond Java primitives, it's a bullshit token PR jesture. The JCP is a far more public process for directing Java than anything we'll ever see from MS for.NET.
You should do this in Java, not Python. Why? Java has a solid security implementation, it's able to recognizing signed binaries, and it's backed by Sun and IBM among others. Nothing against Python but those 3 points are pretty damned hard to refute in an implementation that's all about trust. A runtime compiled based solution that cannot be signed will simple not be considered this type of application. That said, it's your project, this is a suggestion, mod it into oblivion or do whatever you want with it.
Meanwhile, he noted record stores report that blank recordable CDs are outselling recorded CDs, a trend that shows computer users are not only downloading songs, but copying and burning CDs.
That's a gem, using the same logic, if guns outsold waterpistols, that would show that more people are commiting murder. This may come as a shock but CD-Rs can also be used to record data (gasp) or am I the only person in the free world who uses them for this purpose? Also, what if people are creating mix CDs of music they legally purchased? Nah, impossible.
Also, we need to do a little lesson in math:
50 CD-Rs == $10
50 CDs == $750
Does anybody want to bet that even if music CDs were $0.20 each, CD-Rs would STILL outsell CDs.
Nice job distorting the data to fit their pitch though.
Good point, I can see an easy way for the cartel to make it stick, Microsoft could just simply make Longhorn require that DRM be enabled. Voila, DRM everywhere and there's nothing people can do about it if they want to use Windows.
Yeah, it would provide a selling point for Linux but realistically Linux isn't going to push Microsoft to irrelevance in 2 or 3 years or whenever Longhorn eventually ships.
DRM works on the basis a unique ID in the BIOS and a central DRM server. You're always the client in this setup. If the application can't connect to the DRM server, you can't use it, although they make give you a few hours "grace" period. It's not the software on the CD but the activity of linking your license with the BIOS UID in the DRM server that makes it stick.
I don't see any support for Albatron boards on there yet so I guess it's not so easy... well, right now at least... but soon! Oh yes, soon! Yeah, that's the ticket.
Here's a take on it. They could subconsciously take a lax approach towards security to later be able to argue that WinX is soo broken that the only solution is to shell out for an upgrade to WinX+Y. This wouldn't be anything you'd find on a corporate memo but there's certainly truth in the fact that there's money in upgrades, while bugfixing/patch groups are considered pure cost centers. Another possible reason is that given a choice, most developers prefer to spend time on "new" code rather than "fixing" code. I'm not defending MS, just relaying some of what I've seen over the years.
Yeah but those dependencies aren't "breakages", they're just cyclic dependencies. I see your point though about it being a source of frustration. I've never had a problem specifying both packages in a single rpm command (rpm -Uvh a.rpm b.rpm) but your average Lindows user wouldn't know this.
If you want to bring up beefs with RPM, my primary beef is with the rpm database. I understand the need for it but the fact that it's binary instead of XML is a disadvantage because it's relatively easy to corrupt it (ie. aborted installs). I'd like to see a simple XML layout that could be massaged back into a usable form manually.
To go off topic, what are others' takes on the Loki installer? I don't think it dealt with dependencies either (not sure on that) but it had a really slick update mechanism and was Win-like in nature. Since it's fully open source, it should be possible to form a distro around it.
Well, the big 3 RedHat, SuSE, and Mandrake are all standardized on RPM. It's the non-commercial niche distros like Debian and Gentoo that choose not to use vanilla RPM. Personally I don't think there's anything wrong with that, it's how innovation happens, but it really negates the "everybody does it different" argument. RPM is "good enough" and it does the job 95% of the time. A far more important goal I think is the LSB which could eventually lead to a single common x86 Linux RPM for all distros, now that would be an accomplishment. The problem there is that the further you stray from kernel land, the greater the disagreements on how things "should be".
Yep, I was just thinking that myself. Sun makes great products but as a marketing company they're 3rd rate at best. Compare this to Microsoft that makes run of the mill products but are a veritable Saatchi & Saatchi of product marketing. As much as I detest MS for their business practices, they are without a doubt the best software marketers out there by a wide margin over Apple, who I think are the second best hardware/software marketers.
Integration with Excel
Integration with Powerpoint
Integration with Outlook, and by extention,
Integration with Exchange
All of which are irrelevant if you're looking to replace MS Office in the first place.
How about perfect compatibility with everyone in the business world.
You haven't exchanged docs between Office 97 and Office 2K much because there are plenty of incompatibilities that arise between the two without even counting document corruptions.
Right now, in 2003, Linux has no equivalent to Dotnet or WinFS nor any plan for such features . Such VMs and DBs that do exist are completely unexploited (and often impossible to exploit) from the kernel, the core tools and the popular desktops and office applications.
I'm assuming that your referring to a Linux system as a whole and not explicitly the kernel. The reason why these shouldn't be part of the kernel are pretty straightforward,.NET is a development framework and WinFS is a database driven file system. That said, the equivalents for.NET would be Mono / dotGNU and for WinFS you could use Oracle's IFS , not free but then neither is Windows.
That's an awesome defense you just put together though you MNBAL. I've also toyed with infecting code routines and buffer overwrites but have never released anything, just learned from the experience. It may be hard to get his point across in court but if they can't prove that he is the original source of the virus, then it would be hard to get a conviction but then again, IA(also)NAL!
And.Net provides everything that Java provides, but in a language-neutral manner. Much more desirable in my opinion.
.NET is not language-neutral, it supports exactly 4 languages, namely C#, VB.NET, C++ and J#. With the sole exception of C++, these languages are all firmly controlled by Microsoft.
The Karcher one looks very cool but it's $3000 AUD (~$2000 USD). I'm not paying $2K for a vacuum cleaner unless it does a heck of a lot more than just sweep the rugs.
I'll go on the record saying that I hate the business practices of Microsoft the company, however, this patent ruling is a Bad Thing (tm). I was scouring google for some shred of prior art evidence but the patent filing date is October 17, 1994 when the WWW was really in it's infancy. Netscape was at it's 1.0 beta release at the time. The kicker in this patent is that it states "the program object is embedded into a hypermedia document", which I take it prevents applying prior art outside of hypermedia documents. The first plugin I can remember for Netscape was the Adobe Acrobat reader plugin but I'm almost certain that that was later than fall of 1994. Does anybody have an example of a browser plugin that predates October 1994, maybe something in Mosaic?
Getting anything onto a handset takes a very close relationship with the handset maker. That real estate is extremely limited and every bit is accounted for. I'd bet that MS is subsidizing their phone OS to gain traction and that's a dangerous gift for the handset makers to fall for. If MS does manage to capture a majority of the handset market, handset makers can expect them to raise prices and eat into their profit margins.
That said, Nokia is the big fish to contend with in handsets. Due to Symbian, MS won't get Nokia to buy in unless they can get everybody else to buy in first. MS has gotten Samsung, Siemens and now Motorola to at least try their OS. They've even gotten Ericsson to dabble in portions of it. Although they've yet to make quantifiable inroads, the relationships required to turn up the heat are well established and cannot be taken lightly by the remaining of the Big 8, namely Nokia, LGE, Panasonic, and NEC. Keep you eye on the Japanese handset market, they (not Europe or the Americas) dictate the direction of the handset market. If the Embedded Linux Consortium holds together, it could pose the single most significant barrier to the MS Smartphone ever gaining traction.
All the large phone makers (Nokia, Sony Ericsson, Motorola) have very consciously decided against using MS software
As much as I detest Microsoft, Motorola has made the terrible decision of putting out a single MS powered phone (for Orange SA in Europe). Motorola then proceeded to restate that they're firmly commited to Java on Linux for future phones. I know Orange is an MS pawn but it's still disappointing to see Motorola lending credence to it.
Technically wrong, conceptually right. Object variables (not primitives like int / bool /etc) are passed by reference in Java. It's not a pointer in the sense that you can reassign it, it's a reference in the sense that you work on the same object that you passed into the method. These refences are fully under the control of the JVM (see garbage collection for more info). This is why it's extremely difficult to cause a Java program to seg fault. You essentially have to choke off it's resources to get it to bomb.
SGI will likely just ask for a postponement until the IBM case is settled, or, that failing, use stalling tactics until IBM is done eviscerating SCO. Notice how SCO has yet to see the light of a courtroom, lotsa talk, not much walk. SGI may not have buckets of cash but they're still a 10x bigger fish than SCO.
You probably haven't heard but as of JCP 2.5, open source implementations of Java standards are officially supported under the JCP. Thanks to the JCP, we haven't been living in Sun-land since October of last year.
Sun's not a monopoly and don't make it sound like MS gave the entire .NET framework to the ECMA. Nope, just the C# langauge and the CLI, this would be like Sun turning over javac and java to the ECMA but keeping a grip on anything beyond Java primitives, it's a bullshit token PR jesture. The JCP is a far more public process for directing Java than anything we'll ever see from MS for .NET.
You should do this in Java, not Python. Why? Java has a solid security implementation, it's able to recognizing signed binaries, and it's backed by Sun and IBM among others. Nothing against Python but those 3 points are pretty damned hard to refute in an implementation that's all about trust. A runtime compiled based solution that cannot be signed will simple not be considered this type of application. That said, it's your project, this is a suggestion, mod it into oblivion or do whatever you want with it.
BestBuy.com has 50 TDK CD-Rs for $13 - $10 mail-in = $3. I wouldn't count on ever seeing that $10 in the mail though.
Meanwhile, he noted record stores report that blank recordable CDs are outselling recorded CDs, a trend that shows computer users are not only downloading songs, but copying and burning CDs.
That's a gem, using the same logic, if guns outsold waterpistols, that would show that more people are commiting murder. This may come as a shock but CD-Rs can also be used to record data (gasp) or am I the only person in the free world who uses them for this purpose? Also, what if people are creating mix CDs of music they legally purchased? Nah, impossible.
Also, we need to do a little lesson in math:
50 CD-Rs == $10
50 CDs == $750
Does anybody want to bet that even if music CDs were $0.20 each, CD-Rs would STILL outsell CDs.
Nice job distorting the data to fit their pitch though.
Good point, I can see an easy way for the cartel to make it stick, Microsoft could just simply make Longhorn require that DRM be enabled. Voila, DRM everywhere and there's nothing people can do about it if they want to use Windows.
Yeah, it would provide a selling point for Linux but realistically Linux isn't going to push Microsoft to irrelevance in 2 or 3 years or whenever Longhorn eventually ships.
DRM works on the basis a unique ID in the BIOS and a central DRM server. You're always the client in this setup. If the application can't connect to the DRM server, you can't use it, although they make give you a few hours "grace" period. It's not the software on the CD but the activity of linking your license with the BIOS UID in the DRM server that makes it stick.
I don't see any support for Albatron boards on there yet so I guess it's not so easy ... well, right now at least ... but soon! Oh yes, soon! Yeah, that's the ticket.
EOM
Don't do it, you're pretty easy to replace.
Here's a take on it. They could subconsciously take a lax approach towards security to later be able to argue that WinX is soo broken that the only solution is to shell out for an upgrade to WinX+Y. This wouldn't be anything you'd find on a corporate memo but there's certainly truth in the fact that there's money in upgrades, while bugfixing/patch groups are considered pure cost centers. Another possible reason is that given a choice, most developers prefer to spend time on "new" code rather than "fixing" code. I'm not defending MS, just relaying some of what I've seen over the years.
Yeah but those dependencies aren't "breakages", they're just cyclic dependencies. I see your point though about it being a source of frustration. I've never had a problem specifying both packages in a single rpm command (rpm -Uvh a.rpm b.rpm) but your average Lindows user wouldn't know this.
If you want to bring up beefs with RPM, my primary beef is with the rpm database. I understand the need for it but the fact that it's binary instead of XML is a disadvantage because it's relatively easy to corrupt it (ie. aborted installs). I'd like to see a simple XML layout that could be massaged back into a usable form manually.
To go off topic, what are others' takes on the Loki installer? I don't think it dealt with dependencies either (not sure on that) but it had a really slick update mechanism and was Win-like in nature. Since it's fully open source, it should be possible to form a distro around it.
Well, the big 3 RedHat, SuSE, and Mandrake are all standardized on RPM. It's the non-commercial niche distros like Debian and Gentoo that choose not to use vanilla RPM. Personally I don't think there's anything wrong with that, it's how innovation happens, but it really negates the "everybody does it different" argument. RPM is "good enough" and it does the job 95% of the time. A far more important goal I think is the LSB which could eventually lead to a single common x86 Linux RPM for all distros, now that would be an accomplishment. The problem there is that the further you stray from kernel land, the greater the disagreements on how things "should be".
Yep, I was just thinking that myself. Sun makes great products but as a marketing company they're 3rd rate at best. Compare this to Microsoft that makes run of the mill products but are a veritable Saatchi & Saatchi of product marketing. As much as I detest MS for their business practices, they are without a doubt the best software marketers out there by a wide margin over Apple, who I think are the second best hardware/software marketers.
Integration with Excel
Integration with Powerpoint
Integration with Outlook, and by extention,
Integration with Exchange
All of which are irrelevant if you're looking to replace MS Office in the first place.
How about perfect compatibility with everyone in the business world.
You haven't exchanged docs between Office 97 and Office 2K much because there are plenty of incompatibilities that arise between the two without even counting document corruptions.
claim against SCO, for commercial speech that would be entirely protected in the US
That's not true, see Red Hat's lawsuit for a full explaination. It's called "trade libel" and it is not protected speech here in the US.
Right now, in 2003, Linux has no equivalent to Dotnet or WinFS nor any plan for such features . Such VMs and DBs that do exist are completely unexploited (and often impossible to exploit) from the kernel, the core tools and the popular desktops and office applications.
.NET is a development framework and WinFS is a database driven file system. That said, the equivalents for .NET would be Mono / dotGNU and for WinFS you could use Oracle's IFS , not free but then neither is Windows.
I'm assuming that your referring to a Linux system as a whole and not explicitly the kernel. The reason why these shouldn't be part of the kernel are pretty straightforward,
That's an awesome defense you just put together though you MNBAL. I've also toyed with infecting code routines and buffer overwrites but have never released anything, just learned from the experience. It may be hard to get his point across in court but if they can't prove that he is the original source of the virus, then it would be hard to get a conviction but then again, IA(also)NAL!
And .Net provides everything that Java provides, but in a language-neutral manner. Much more desirable in my opinion.
.NET is not language-neutral, it supports exactly 4 languages, namely C#, VB.NET, C++ and J#. With the sole exception of C++, these languages are all firmly controlled by Microsoft.
The Karcher one looks very cool but it's $3000 AUD (~$2000 USD). I'm not paying $2K for a vacuum cleaner unless it does a heck of a lot more than just sweep the rugs.
I'll go on the record saying that I hate the business practices of Microsoft the company, however, this patent ruling is a Bad Thing (tm). I was scouring google for some shred of prior art evidence but the patent filing date is October 17, 1994 when the WWW was really in it's infancy. Netscape was at it's 1.0 beta release at the time. The kicker in this patent is that it states "the program object is embedded into a hypermedia document", which I take it prevents applying prior art outside of hypermedia documents. The first plugin I can remember for Netscape was the Adobe Acrobat reader plugin but I'm almost certain that that was later than fall of 1994. Does anybody have an example of a browser plugin that predates October 1994, maybe something in Mosaic?