I haven't had any trouble with any MS Office files I've thrown at OpenOffice. Granted I mostly open MS Word documents but they've all opened fine. Far more impressive to me was when I dug out an MS Office for Mac file from about 15 years ago and THAT opened in OpenOffice even though MS Word for Windows wouldn't have anything to do with it.
So while I'm sure there are certain files which don't convert well I've been extremely happy with OpenOffice's support so far. I'm less happy about the general level of bloat and lower level of usability that comes with the product. I can't help wonder who thought it would be a great idea to toss in Python, Java, StarBasic and god knows what other runtimes into this app. There is a very cobbled together feel about the whole thing.
Winforms were originally based on Windows controls which may be why they're quirky. For example, they more or less assume that each control is a window in its own right with a WNDPROC which messes with all sorts of things such as z-order, clipping, theme etc. And of course Mono has to hack around any Windows dependencies. However, these days you can use WPF instead which is a lot more platform agnostic and the UI is defined in XML which is a huge bonus.
Anyway (and this isn't necessarily QT's fault), if your goal is cross-platform development then choosing C++ as your language introduces heaps of problems all by itself so its not without its own quirks.
Prices of previous OS X upgrades haven't been exactly cheap either and seem to come 2 or 3 times for every one for Windows. Unless you skip them, chances are you're paying as much as Windows costs for an upgrade anyway.
That doesn't excuse Microsoft, but the point is Apple aren't exactly better. Especially if you drop a few point releases behind you may as well not exist as far as most new software is concerned. At least Windows tends to be better supported as well for its lifetime.
The PS3 currently has the highest attach rate of all next gen consoles, so that's definitely not it's problem. It absolutely does need to be cheaper though. I think a $299 Slim model would sell shitloads.
Activision like most huge companies employes teams to write middleware libraries and tools which probably means a substantial portion of title specific code is platform neutral. Games hit the middleware, not the hardware except in some timing critical places. On top of that, the PS3 would share virtually 100% of the graphical and audio assets with its PC and 360 counterparts. The upshot is developing for 360/PC/PS3 is not vastly more expensive than developing for 360/PC. Compare to the Wii where virtually all of the game code and assets would be different.
Therefore I don't accept the motivations for this statement. More likely Sony and Activision are in a pissing match over something like certification fees, PSN fees, technical requirements, 3rd party accessories or similar and this is Activision making their power play. Any way, a price cut is bound to happen sooner than later. Everyone knows its needed, including Sony, especially if the Slim is inbound as it is.
Sony execs aren't dumb. They aren't going to announce price cuts until they happen.
Especially with a slim model on the way. Anyway its fairly likely what Sony will do since they've done it before. When the new model appears they'll dump the price on the old model, bundle the new model with some goodies and sell at a premium. Then when the old are cleared out, unbundle the new model and continue selling at the new lower price.
People with large legacy infrastructures who didn't want to pay to have their software converted to Solaris, BSD or Linux. They buy the upgrades so they can run old software on new hardware because in the short term it's cheaper.
I'm surprised they bothered. If systems are that legacy it would probably be cheaper to virtualize them. More interesting but perhaps legally iffy would be to fund an open source project to emulate the SCO system calls and core libraries. Something like lxrun but for SCO so that apps can be ported and run on any other x86 OS.
No browser implements HTML properly. In some instances there is no such thing as "proper" since the spec is ambiguous, contradictory or forgiving, or the content abuses lax enforcement of doctypes leading browsers needing to implement all kinds of the quirks. Even if HTML 5 were rigourously defined and backed up by proper compliance testing, you only have to look at HTML 4 or indeed proper PNG support to realise how long it will take for browsers to properly support it. Even if HTML 5 were properly supported by say, Google Chrome, is it at all likely for the majority of web users to switch to that browser? Of course they won't. They'll stick with whatever they have until they are compelled to upgrade.
So it's no surprise sites turn to Flex, Silverlight or JavaFX. While they are proprietary technologies they do generally work as claimed and even in a cross-browser and cross-platform manner. It's also easy for sites to persuade people to download & install the plugins without the trauma of upgrading or replacing their browser since the browser will help them do it.
Therefore I don't see HTML 5 supplanting RIA plugins for a very long time if ever. It would require decent support by all leading browsers. In some instances such as Internet Explorer, there is even a very major conflict of interest which makes it unlikely to happen. Aside from these hurdles, another major issue are AJAX toolkits and development environments. Frankly developing AJAX stinks for all sorts of reasons, and I don't see that situation changing much either.
I've led large teams of developers and I guarantee that even if you write coding standards, or have a common coding style for the project that somebody in your team will either ignore it, or do their own thing. The guidelines might say don't use hungarian but somebody still will. Code reviews are an excellent way to enforce standards and ensure a base level of code quality across the board. Aside from general style, reviews mean you catch people not programming defensively, not catching exceptions, not writing readable code, not logging, using weird notation, weird indentation and so on. After getting drubbed a few times in reviews most programmers are a lot more conscious of the way they write code and the overall standard is raised. After that reviews are still a useful practice because I've lost count of the number of potential bugs they've caught.
Now maybe there are reasons that reviews should be conducted in one way or another. My preference is formal group reviews for brand new code pr new team developers and over-the-shoulder reviews for substantial checkins thereafter. Between the two I guarantee you save more time than if the bugs went in and were only uncovered later in QA or worse, in production.
No, common sense. As in a polite way of saying OBVIOUS. It is OBVIOUS that custom firmware is being predominantly used for piracy. It is OBVIOUS that the R4 is being predominantly used for piracy.
I own a PSP 1000. I would not consider buying PSP Go unless there was a upgrade path. I own 20 or so games for my PSP and if I were to buy the new device I would like to carry them over. If I can't do this, then what the hell is the point of me buying a Go at all? After all, I could always slap an 8Gb memory stick in my existing PSP and get the best of both worlds.
If this were a PSP2 then perhaps I might understand, but it isn't. I'll wait and see of course, but no upgrade path means no sale for me.
But are the developers actually losing money from piracy?
Yes is the answer. You can't assume that if there are 100,000 pirate copies that the publisher has lost that many sales. There are lots of lamers who wouldn't pay for anything. But even if 1/5 of those copies could have been legitimate then that is still a very substantial loss of revenue.
I haven't really been much in the PSP homebrew scene but I know that for the DS/Wii most of the time the real developers who develop the technologies do disable it, however because its an open platform any coder can code and run something that helps piracy.
The R4 ships out of the box to play.ds files. I doubt very many people are buying it to run moonshell.
There is no way of quantifying how many people using custom firmware do it for piracy and how many for homebrew. But common sense dictates that the vast majority use it for piracy.
If genuine homebrewers are shocked by this accusation, there is a simple solution. Disable iso record / playback functionality in custom firmware. Let people build homebrew apps but prevent people from playing warez. Let's see how popular custom firmware is then.
The PSP Go has no UMD, so what happens for someone who has UMD games already?
I hope that existing users can register their games through PSN. Perhaps a firmware update for the UMD models would allow people to register games online. Alternatively Sony should sell a UMD docking station for the Go and allow syncing that way. The software would have to occasionally re-validate games to prevent people renting / borrowing games but it must be feasible.
It would be very odd if Sony don't offer existing users any migration path
It loses sales because the majority of people running custom firmware do so to play pirated games. Same goes for the R4 device on the DS. Piracy means less revenue for Sony and less revenue to the publisher. It also means less incentive for publishers to bother with the platform, or if they do to spend as much on development.
What isn't forgivable is that one of the columns on this bug spreadsheet is "Publicly Available" which implies to me that there is a list I'm not seeing of fixed bugs which would be annoying and probably even non-fixed bugs they purposefully suppress from public knowledge which is alarming!
The chances are that any non-visible bugs are security related. Why are you surprised that Microsoft may choose to hide bug fixes for security issues when the percentage of people who have applied SP2 stands around 0% at the moment?
Most major open source projects hide security bugs too by flagging the bug private or only discussing it in invite-only mailing lists until a solution is found. For example Firefox usually only throws open security bugs after they're fixed and an update is released.
Will Microsoft disclose info about the bug after the patch is applied? I wish they would, but its totally understandable why they don't beforehand.
If they hadn't done that, nobody would be using it for real world projects. In Linux fairy land, you don't have to worry about backwards compatibility. If something doesn't work, you fork and fix it, resulting in a profusion of different levels of compatibility. Being able to use ActiveX or invoke and use Win32/OLE objects in.NET allows us to bridge the gap between those technologies without investing many man years completely re-writing what we know already works. I can write WPF or Windows Forms front ends to OLE servers we've been using for ten years.
Well that's not true at all. Java is living proof that real world applications do not need to be tied to operating systems at all. There is no "fairy land" about it. When I'm developing Java apps (and I also develop Flex and.NET apps), I tend to develop on Windows. I am genuinely surprised if my code doesn't work when deployed to Unix (which is not Linux as it happens). The operating system is the least of my worries. If there are issues its usually with deployment plans for different J2EE app containers.
And yes Java lets you make native calls via JNI but the practice is not endemic. It generally only occurs in low level libraries such as SWT, or interfacing to specific hardware, or to legacy code. There are even 3rd party tools for importing and generating stub wrappers for ActiveX and COM components if you want to. It wouldn't be hard to write a JNI file for talking with OLE from scratch either. I've done it myself from JRI (JNI's predecessor). It's fairly simple in fact if your servers are non visual. But the Java language doesn't contain keywords to encourage calling unmanaged DLLs and the tools don't contain wizards for automatically importing controls. Java developers generally make no assumptions about the target platform either for reasons of portability.
As for "bridging the gap" there are ways and means Microsoft could have offered tools while still discouraging the practice. The simplest would have been popup warnings in the tool warning against the practice. More involved would have been to force unmanaged calls to be defined by an interface and reside a separate assembly which can be overridden at runtime. Even better if parts of the.NET runtime such as Windows.Forms weren't broken by design in the first place, making assumptions about the underlying implementation. It's very clear what Microsoft intended and in that regard they succeeded as evidenced by Mono's failure to work with a large number of applications.
It's useful if you want to be literally 8 years behind the curve. I'd add that any app which uses IE,.NET, MSDE or any other runtime for XP won't work properly until such time as WINE implements adequate replacements.
Seriously, Microsoft have got other things to do than worry about a tin-pot emulation project..NET advances are good in themselves for the developers who use those technologies. Microsoft don't have to stop advancing the technology just because Mono needs to catch up.
Actually Mono serves as an excellent foil for Microsoft. If somebody points out that Java is write-once, run-anywhere (and it generally is), they can point to Mono and say "us too". Except of course it isn't. It's always behind and fails hard for more real world.NET apps that want to PInvoke or use ActiveX. Mono can never be compatible because Microsoft made it far too convenient to call unsafe / unmanaged code.
If they cared about Linux support, they'd release.NET for Linux, but the don't and neither do the vast majority of Windows developers.
Microsoft releasing something for Linux is no indication they care. At one point they released an Internet Explorer for Unix, ensuring to give it away for nothing vs the licence fee Netscape charged at the time. Once Netscape went broke, IE for Unix was canned. They once licenced the Win32 APIs for Unix too but yanked support leading to lawsuits.
As it happens Microsoft has released a codec pack for Mono on Linux but I fully expect them to allow it to bitrot or be ignominiously killed at any time. This is what Microsoft has done before and I doubt this time will be any different. Even while there is a codec pack it puts a binary dependency between Mono and Microsoft, and the pack lacks DRM functionality which basically cripples or breaks some sites.
Wrong. The loss is just as much yours and the users'. If I was an evil M$ overlord, I would definitely attempt to mess up projects like wine, and the easiest way to do this is to find that key people on whom everything relies and try to influence those in the wrong direction. Seen from this viewpoint, it is easy to see the loss is not "theirs" at all. And even if this is not the case, the point is the same.
Actually the easiest way is what Microsoft is already doing. Make the Win32 API a rats nest of undocumented functions and behaviour. Then throw in some huge dependencies on binary components such as Internet Explorer to guarantee incompatibility. Then start deprecating APIs and reinventing the functionality again, preferably again with undocumented behaviour and binary dependency on some undocumented DLL. Rinse and repeat. WINE will always be playing catchup.
Microsoft did it to WINE and now they're doing it to Mono. Mono has found itself in the same boat and it will never, ever catch up with.NET.
Possibly the first time. I still remember the first and only time I was sedated to remove a tooth as a kid. They made out it was a game that I had to put the mask on and breath deep. I know in hindsight they probably couldn't have proceeded otherwise but it still felt like a betrayal of trust to have been lied to like that. I expect that if I had gone back to the dentist I would have fought long and hard before falling for that trick again.
I know Microsoft is being its usual self, but perhaps the ODF alliance should promoting a certification program and a compliance logo to raise the quality of interoperability of ALL ODF based applications.
Sites don't directly use Java but there are plenty of JNLP style apps. Also, JavaFX *may* spark some kind of mini-resurgence which means more sites use Java for video playback or random other things.
I say may because Flex / Flash is pretty embedded and Microsoft is moneyhatting its way into the scene. Sun doesn't have money so its almost a charity case at this time, relying on good will from mobile phone companies and Java devs.
Anyway, Apple's "support" of Java is pretty pathetic. They're usually a year or more behind the curve and its not acceptable.
Slashdot Mirror
So while I'm sure there are certain files which don't convert well I've been extremely happy with OpenOffice's support so far. I'm less happy about the general level of bloat and lower level of usability that comes with the product. I can't help wonder who thought it would be a great idea to toss in Python, Java, StarBasic and god knows what other runtimes into this app. There is a very cobbled together feel about the whole thing.
Anyway (and this isn't necessarily QT's fault), if your goal is cross-platform development then choosing C++ as your language introduces heaps of problems all by itself so its not without its own quirks.
That doesn't excuse Microsoft, but the point is Apple aren't exactly better. Especially if you drop a few point releases behind you may as well not exist as far as most new software is concerned. At least Windows tends to be better supported as well for its lifetime.
But will he turn yellow like some of his Macbooks?
The PS3 currently has the highest attach rate of all next gen consoles, so that's definitely not it's problem. It absolutely does need to be cheaper though. I think a $299 Slim model would sell shitloads.
Therefore I don't accept the motivations for this statement. More likely Sony and Activision are in a pissing match over something like certification fees, PSN fees, technical requirements, 3rd party accessories or similar and this is Activision making their power play. Any way, a price cut is bound to happen sooner than later. Everyone knows its needed, including Sony, especially if the Slim is inbound as it is.
Especially with a slim model on the way. Anyway its fairly likely what Sony will do since they've done it before. When the new model appears they'll dump the price on the old model, bundle the new model with some goodies and sell at a premium. Then when the old are cleared out, unbundle the new model and continue selling at the new lower price.
I'm surprised they bothered. If systems are that legacy it would probably be cheaper to virtualize them. More interesting but perhaps legally iffy would be to fund an open source project to emulate the SCO system calls and core libraries. Something like lxrun but for SCO so that apps can be ported and run on any other x86 OS.
So it's no surprise sites turn to Flex, Silverlight or JavaFX. While they are proprietary technologies they do generally work as claimed and even in a cross-browser and cross-platform manner. It's also easy for sites to persuade people to download & install the plugins without the trauma of upgrading or replacing their browser since the browser will help them do it.
Therefore I don't see HTML 5 supplanting RIA plugins for a very long time if ever. It would require decent support by all leading browsers. In some instances such as Internet Explorer, there is even a very major conflict of interest which makes it unlikely to happen. Aside from these hurdles, another major issue are AJAX toolkits and development environments. Frankly developing AJAX stinks for all sorts of reasons, and I don't see that situation changing much either.
Now maybe there are reasons that reviews should be conducted in one way or another. My preference is formal group reviews for brand new code pr new team developers and over-the-shoulder reviews for substantial checkins thereafter. Between the two I guarantee you save more time than if the bugs went in and were only uncovered later in QA or worse, in production.
No, common sense. As in a polite way of saying OBVIOUS. It is OBVIOUS that custom firmware is being predominantly used for piracy. It is OBVIOUS that the R4 is being predominantly used for piracy.
If this were a PSP2 then perhaps I might understand, but it isn't. I'll wait and see of course, but no upgrade path means no sale for me.
Yes is the answer. You can't assume that if there are 100,000 pirate copies that the publisher has lost that many sales. There are lots of lamers who wouldn't pay for anything. But even if 1/5 of those copies could have been legitimate then that is still a very substantial loss of revenue.
I haven't really been much in the PSP homebrew scene but I know that for the DS/Wii most of the time the real developers who develop the technologies do disable it, however because its an open platform any coder can code and run something that helps piracy.
The R4 ships out of the box to play .ds files. I doubt very many people are buying it to run moonshell.
If genuine homebrewers are shocked by this accusation, there is a simple solution. Disable iso record / playback functionality in custom firmware. Let people build homebrew apps but prevent people from playing warez. Let's see how popular custom firmware is then.
I hope that existing users can register their games through PSN. Perhaps a firmware update for the UMD models would allow people to register games online. Alternatively Sony should sell a UMD docking station for the Go and allow syncing that way. The software would have to occasionally re-validate games to prevent people renting / borrowing games but it must be feasible.
It would be very odd if Sony don't offer existing users any migration path
It loses sales because the majority of people running custom firmware do so to play pirated games. Same goes for the R4 device on the DS. Piracy means less revenue for Sony and less revenue to the publisher. It also means less incentive for publishers to bother with the platform, or if they do to spend as much on development.
What isn't forgivable is that one of the columns on this bug spreadsheet is "Publicly Available" which implies to me that there is a list I'm not seeing of fixed bugs which would be annoying and probably even non-fixed bugs they purposefully suppress from public knowledge which is alarming! The chances are that any non-visible bugs are security related. Why are you surprised that Microsoft may choose to hide bug fixes for security issues when the percentage of people who have applied SP2 stands around 0% at the moment? Most major open source projects hide security bugs too by flagging the bug private or only discussing it in invite-only mailing lists until a solution is found. For example Firefox usually only throws open security bugs after they're fixed and an update is released. Will Microsoft disclose info about the bug after the patch is applied? I wish they would, but its totally understandable why they don't beforehand.
Well that's not true at all. Java is living proof that real world applications do not need to be tied to operating systems at all. There is no "fairy land" about it. When I'm developing Java apps (and I also develop Flex and .NET apps), I tend to develop on Windows. I am genuinely surprised if my code doesn't work when deployed to Unix (which is not Linux as it happens). The operating system is the least of my worries. If there are issues its usually with deployment plans for different J2EE app containers.
And yes Java lets you make native calls via JNI but the practice is not endemic. It generally only occurs in low level libraries such as SWT, or interfacing to specific hardware, or to legacy code. There are even 3rd party tools for importing and generating stub wrappers for ActiveX and COM components if you want to. It wouldn't be hard to write a JNI file for talking with OLE from scratch either. I've done it myself from JRI (JNI's predecessor). It's fairly simple in fact if your servers are non visual. But the Java language doesn't contain keywords to encourage calling unmanaged DLLs and the tools don't contain wizards for automatically importing controls. Java developers generally make no assumptions about the target platform either for reasons of portability.
As for "bridging the gap" there are ways and means Microsoft could have offered tools while still discouraging the practice. The simplest would have been popup warnings in the tool warning against the practice. More involved would have been to force unmanaged calls to be defined by an interface and reside a separate assembly which can be overridden at runtime. Even better if parts of the .NET runtime such as Windows.Forms weren't broken by design in the first place, making assumptions about the underlying implementation. It's very clear what Microsoft intended and in that regard they succeeded as evidenced by Mono's failure to work with a large number of applications.
It's useful if you want to be literally 8 years behind the curve. I'd add that any app which uses IE, .NET, MSDE or any other runtime for XP won't work properly until such time as WINE implements adequate replacements.
Actually Mono serves as an excellent foil for Microsoft. If somebody points out that Java is write-once, run-anywhere (and it generally is), they can point to Mono and say "us too". Except of course it isn't. It's always behind and fails hard for more real world .NET apps that want to PInvoke or use ActiveX. Mono can never be compatible because Microsoft made it far too convenient to call unsafe / unmanaged code.
If they cared about Linux support, they'd release .NET for Linux, but the don't and neither do the vast majority of Windows developers.
Microsoft releasing something for Linux is no indication they care. At one point they released an Internet Explorer for Unix, ensuring to give it away for nothing vs the licence fee Netscape charged at the time. Once Netscape went broke, IE for Unix was canned. They once licenced the Win32 APIs for Unix too but yanked support leading to lawsuits.
As it happens Microsoft has released a codec pack for Mono on Linux but I fully expect them to allow it to bitrot or be ignominiously killed at any time. This is what Microsoft has done before and I doubt this time will be any different. Even while there is a codec pack it puts a binary dependency between Mono and Microsoft, and the pack lacks DRM functionality which basically cripples or breaks some sites.
Actually the easiest way is what Microsoft is already doing. Make the Win32 API a rats nest of undocumented functions and behaviour. Then throw in some huge dependencies on binary components such as Internet Explorer to guarantee incompatibility. Then start deprecating APIs and reinventing the functionality again, preferably again with undocumented behaviour and binary dependency on some undocumented DLL. Rinse and repeat. WINE will always be playing catchup.
Microsoft did it to WINE and now they're doing it to Mono. Mono has found itself in the same boat and it will never, ever catch up with .NET.
Possibly the first time. I still remember the first and only time I was sedated to remove a tooth as a kid. They made out it was a game that I had to put the mask on and breath deep. I know in hindsight they probably couldn't have proceeded otherwise but it still felt like a betrayal of trust to have been lied to like that. I expect that if I had gone back to the dentist I would have fought long and hard before falling for that trick again.
I know Microsoft is being its usual self, but perhaps the ODF alliance should promoting a certification program and a compliance logo to raise the quality of interoperability of ALL ODF based applications.
I think you have lost your marbles.
I say may because Flex / Flash is pretty embedded and Microsoft is moneyhatting its way into the scene. Sun doesn't have money so its almost a charity case at this time, relying on good will from mobile phone companies and Java devs.
Anyway, Apple's "support" of Java is pretty pathetic. They're usually a year or more behind the curve and its not acceptable.