Sure. And if we were talking about forward binary compatibility, which would require accurate predicting the future, that would be a valid argument.
We're not, we're talking about intentionally breaking binary backward compatibility, so that when you force someone to buy a new OS when they want to buy a computer, you force them to also re-buy application software, which they already own, to run on that OS.
This isn't any different than any other form of tying, where you leverage a monopoly in desktop OS's to force, for example, use of a particular browser. The money spent on Office 2000 is a sunk cost, and you're forcing them to re-spend.
I have just had a quick google and there are lots of posts claiming to have it working on windows 8 however, you are looking back five versions of office before you find one which does not work.
Please name another software vendor who provide this level of support.
Please name another software vendor with a monopoly in desktop operating systems, and I'll be happy to describe how they provide binary backward compatibility to avoid leveraging their monopoly position to force re-purchase of existing software by not tying that software to a particular platform.
I have read this a number of times and I can only assume you have never used a windows computer. The versions of office and windows are in no way restricted, I am running components form Office 2003, 2010 and 2013 on Windows 7 and Office XP, 2003 and 2010 on windows XP.
Windows Vista, 7 and 8 all have compatibility mode which tries with varying degrees of success to fool older pieces of software that they are running old versions of windows.
Further, Microsoft can support Windows XP, they just want more $$$ to do it (so, if they can do it for one company, and the goods they're selling are infinite, why can't they for all the rest?).
Actually, no. The reason they are willing to continue to provide the updates to some entities is because of the purchase and support contracts they entered into as part of a bulk purchase agreement. So they offer it not because they want more $$$, but because they are contractually obligated to do so. They'd just as soon give all these companies free updates to Windows 7 (or whatever) to get released from these contracts, which is the reason they are unwilling to extend support, for any amount of $$$, to other people caught in the same situation, but without benefit of contracts adding additional clauses on top of the clauses present in the public licenses themselves.
The paper (if you read it) claims that the requirement should be enforced based on the Microsoft having monopolistic power in the marketplace. Apple doesn't wield monopolistic power in the marketplace for desktop operating systems.
This is all a bit more subtle than that. The problem is; how do you define the market? When you go out and buy a computer and operating system in a shop, it's clear that Apple an Microsoft have a duopoly (which is a bit dodgy when you consider that they have cooperation on patents locking competitors out of the market; but we will leave that aside). When you come to look after your old computer that is no longer true. Microsoft will not generally provide OSs for Apple computers and Apple will certainly not willingly provide them for PCs.
That's not true. Microsoft will happily sell you Windows to run on anything capable of running it, and Apple went out of their way to support ACPI and SMP tables that are acceptable to Microsoft OS's, even though it required adding some substantial EFI modules, as well as providing driver support for Windows for Apple proprietary hardware.
Apple will certainly not provide Mac OS X for non-Apple hardware; however, this has been upheld multiple times in court cases as being acceptable because Apple does not wield monopolistic power in the desktop computer marketplace. Courts have led exactly the opposite in findings of fact when it comes to Microsoft.
In this instance, we define "market" as "market for desktop computer operating systems".
This means that, whilst Apple does not have a monopoly on computing in any way, they do have a monopoly on support for old Apple computers.
Agreed; however, the IRS amortization schedule on computer hardware is 5 years - and unlike Windows on PC hardware, Apple desktop computers consist of both the hardware and the software, not just the software running on white-box/grey-box machines. You could make the argument on the basis of hardware only for hardware sold with Windows installed, if it was considered part of the hardware. But again, we have court precedent forcing companies such as Dell and HP to offer white-box/grey-box hardware without the so-called "Windows tax", This means that the software is not subject to the same accelerated depreciation.
Specifically, IRS Publication 544, Chapter 2, under "depreciable business assets".
The correct answer would probably be that there is already competition in this market. By changing to a Linux os perating system you can maintain your 15 year old computer fully supported. Unfortunately, in many cases that's not true. Device manufacturers only provide full documentation and support to Microsoft and the Linux drivers cannot be guaranteed.
This is very much a red herring; while Open Source OS vendors and advocates, such as FreeBSD and Linux would dearly love for this to be the case, the problem is actually not with the platform, but with the capitol investment as a lump sum business asset, in software components, such as Microsoft Office and other components which can be assembled together with glue code to implement vertical market solutions.
Microsoft explicitly does not support Visual Basic, Visual Studio, Microsoft Access, or other software on non-Windows Platforms for the use model of implementing vertical market solutions (i.e. neither Linux nor FreeBSD nor Mac OS X have such support).
Further, the software packages of this type from Microsoft are tied to a specific version of the Windows Operating system; that is, you can not take a version of Office intended for use on Windows XP, and run it on Windows 7 or later versions of the Microsoft OS platform. This explicit and intentional tying is monopolistic in nature. Further, the glue code for the vertical market systems previously mentions, *also* will not run on non-XP platforms.
Personally, I think they are going about this the wrong way. The Gov't should be sending Death Squads to kill all members of any household still running XP, or running any version of IE less than 10. Brutal? Maybe. But, boy will it do wonders for the social lives of us Web Developers.
I might agree, if the versions of IE eligible for that treatment also included greater than or equal to 10...
I am a critic of M$ but I do not think they should be required by law.
Only in the case of some sort of long-term contract that is still in effect, that mentions specifically updating software until a time in the future...unless that is the case.
These laws are complex and the photocopier example is interesting.
A potentially more interesting example is replacement auto parts, which automobile manufacturers are required by law to stock for 10 years after the last date of manufacture so that owners of the vehicles can repair them or have them repaired by a third party. Since the last ship date for Windows XP was the last contractual date that Microsoft allowed vendors to bundle it with new computers, that would give them about an 8 year support requirement for "replacement parts". Note that the automobile example would apply to the GM ignition switch, which had an engineering change to correct a design defect - and any security flaw is technically a design defect.
I think that the more companies attempt to treat intellectual property as real property, the more that the negative aspects of real property law should be applied to their products.
E.g. if I use your patent, and you don't stop me using it, then I've engaged in adverse possession, and have "established an interest" in the intellectual property which you must therefore allow me to continue to use, just as if my driveway had been over the property line for 10 years, and you didn't do anything about it, or if I'd been parking my car at your curb, and it didn't bother you until I started parking my RV there and blocking your view.
The paper's argument seems to be along similar lines of thinking.
Photocopier vendors do not open the controller software up to competitors / vendors who provide support. They just give them specs for replacement parts.
Do you force Apple to let 'competitors' support OS X 10.5 on G5 Macs? Do you force Google to let competitors still support Google Wave?
The paper (if you read it) claims that the requirement should be enforced based on the Microsoft having monopolistic power in the marketplace. Apple doesn't wield monopolistic power in the marketplace for desktop operating systems.
If only it were possible to do challenge/response! Using a pre-arranged CERT, so that the drone sends a challenge for each command that has to be encrypted with the shared secret before the drone would accept it!
If you target one platform, you target PC's, unless the market for your application is graphic artists, musicians, etc., then you target Macs.
This is the important part. You don't target based on the number of devices sold--the market share--you target based on the platform that your intended audience is using.
Clearly, as an app developer, my intended audience is people with the willingness to part with money for my application, which is generally not the people who buy on the basis of price sensitivity.
But even foregoing that, if I develop for iOS, I basically have to tarket 7 platforms, while if I develop for android, I have to target many hundreds of devices instead.
Unless I'm Roxio, and my strategy is to own an app category on all devices, and I can afford it, due to an existing iPhone success, my ROI on developing for android is very low.
Can you identify a single market segment, other than "poor people who have no money to spend on apps" who would be interested in me developing my app for android instead of iOS?
PC's historically have had a lot more software available for them than Macs because you have a larger target market. If you target one platform, you target PC's, unless the market for your application is graphic artists, musicians, etc., then you target Macs. If you target two markets, you target PC's and Macs, and you don't target Linux.
If I target iOS because I have a product that will work on a tablet/mobile platform, then I have the largest possible market. I'm guaranteed a practically forced upgrade to the most recent version of the OS the platform can run, and I'm guaranteed that the device is going to have the same set of sensors and input methods as every other device.
I'm guaranteed that, even though it's not in AT&T's best interests, given their contract model, to not have the carrot of me not being able to run the latest OS unless I re-up my contract, I'm going to get the latest OS anyway, and screw what AT&T wants, and screw their business model, because that's what Apple wants.
For Android, I have to target a lot of versions of the OS; I practically have to target whatever the version was at the time they did the repo code freeze on the android sources, and started the platform port. I have to target different screen resolutions. I have to target different input methods. I have to target different camera capabilities, resolutions, directionality, and so on.
Practically speaking, each android device is an island. Some have a lager market share. If I wanted to target 6 platforms, 2 of them would be iOS, 1 of them would be iOS on iPhone 5 (different aspect ratio), and the other 3 would probably be Samsung Galaxy products (2 phones and a tablet, based on market share).
If you could resolve the android version difference problem, that'd go a hell of a long way toward making android competitive. It would require changing the android development model, and some of the partnership agreements.
Instead, Google is concentrating on forcing branding onto the boot screen, and forcing apps onto the device by default. The apps are a good thing, in general, since they tend to rationalize the user experience, but not the same way the VGA standard rationalized the user experience on PC's: minimally, there should be resolution and aspect ratio requirements for android - they matter a hell of a lot more to establishing an applications base than putting up a logo at boot time.
The walls on Google's walled garden are also rather porous. They are more "We won't let you play with the toys we have" rather than "we will keep the bad guys out". And it shows. It shows that other people can run android app stores, that they do, and that there's a huge amount of malware out there in those place. They show in the balkanization of the market by OEM vendor stores, and by carrier stores.
It's crap that I can buy an iOS device, and get "The Apple Experience" - a uniform thing across all the devices - but that I can't buy an android device and get "The Android Experience" - unless you call a balkanized chaos "The Experience".
So yeah, as a developer, I don't target android unless I'm Roxio and have more money than God to spend on programmers for platforms where I'm going to end up selling 50 copies of the game that everyone has, and then sell follow-on modules on a monthly basis until the cows come home, in order to monetize that investment over a long (I don't care how long; I'm not living hand to mouth, I'm Roxio!) period of time.
So yeah, android has shit apps. Make it a uniform platform, instead of me trying to develop for the Mac and the Apple IIe and the Ohio Scientific, and the Orange Micro, and the TI-99/4A, and the Timex Sinclair Z-8000, and the Tandy CoCo, and the Wang word processing station, and the... or keep your balkanized mosaic of "Choice, man! Yeah! Choice!" and write your own damn software.
The problem is that this is still a "success story".
If the success story earns slightly above average, then you probably don't want to know what the average earnings are.
I'm somewhat confused. Yes, it's a success story; how is that a problem? How is it an example of the OP's thesis? How is it in any way applicable to the OP's thesis, given that his thesis involves college students, and these students were, at the time of their success, 2-3 years away from making a decision in that regard?
$30 an hour is shit for good programmers. I earn over double that as base and have full benefits.
$30 an hour is actually fantastic for these kids.
They're not good programmers, they're high school sophomores, one is barely old enough to get a restricted drivers license, they don't have enough formal education that they wouldn't be lost in a team meeting where "big-O" notation or "trie" were mentioned, and they wouldn't be able to communicate with their peers effectively, even if it was just over email to avoid the whole ageism thing.
That's $62,400 per year, and even if we split that between two of them, that's $31,200 each, which is 25% more than the college interns with three years of college toward a CS degree were making.
And even divided, it's higher than the starting salary of a public school teacher with a masters in education (because it's required to get the job and the teachers union membership) in the San Francisco Unified School district.
Well, the obvious answer is "move to California"; California courts have invalidated out of state non-competes former employers in other states have attempted to enforce against workers in California.
Practically speaking, unless there's an arbitration clause or a venue clause in the non-compete that sticks it to Massachusetts, there's really very little the employer can do. The recent Atlantic Marine decision on the venu clause strengthens somewhat the requirement that it be part of the signed agreement at the time.
Thank you, I've always wondered why these types of waste were not reprocessable. A friend of mine went to ASU in the '70s/'80s and they had an Indian physicist called Dr. Roy (no idea what the last name was) who claimed to have a method for safely disposing of nuclear waste, never heard of the program going live.
France doesn't have a use for the plutonium because they do not run a sufficient ratio of Pu reactors or breeders to produce the Pu to fuel those reactors.
This was France's answer to the "nonproliferation problem" which Jimmy Carter dealt with by disallowing reprocesseing in the U.S. altogether; this ban has been lifted, reinstated, and lifted again, but in general, it's not worth building something over the period of a decade if it will potentially end up banned again. So we have a plant, we only have a couple DOE operated breeder facilities for weapons grade materials, and the commercial reprocessing plant that was recently just mothballed.
Most of the problems at this point are political, and most of the costs are either protest-driven or redesign-the-plant-while-building-it-driven rather than actually technical.
No one at being recruited is at will. These aren't tech support jobs they're design and engineering teams. These folks have very detailed contracts. Your not working a new products without one.
You're quite wrong. Having worked on secret projects at both Apple and Google, the only thing you get to sign extra above and beyond your original employment agreement, which is primarily a non-disclosure agreement, is layered non-disclosure agreements.
It's actually quite funny, since they bring you an agreement with a project codename on it that you aren't allowed to discuss under your original agreement, and then after that NDA, you are now allowed to learn the codeword for the project you're going to be working on, and you sign an NDA for that project, too.
Very, very rarely you will be asked to sign a vendor or partner NDA, but if you're asked to do that, you are generally compensated for the signing, because it means not working in that area for another company for a couple of years, and the compensation is to pay you for foregoing the opportunity.
FYI, everyone below management director level, including line managers, are "at will", at least in Apple and Google in California, and it's likely the case elsewhere, since some of the work is considered by the Franchise Tax Board to take place in California, if you are managed from California, so California gets to collect income tax on it. The two "Distinguished Engineers" I know at Apple I've discussed it with are also "at will", rather than contract employees.
I'm not sure about the people at director level or above at Apple, or above directory level at Google, since, frankly, the topic has never come up in casual conversation, and generally people tend not to talk about their compensation anyway, unless you are a very close friend or family member.
Generally, both companies rely on options maturation (or RSU - Google calls them GSUs and ties them to performance) vesting schedules to act as "golden handcuffs", rather than contracts. You're generally not a high level contract employee without a parachute (silver or golden).
In case you are wondering, non-competes are also not legal in California, unless the competition occurs as side work during your employment at the company, and generally are not considered legally enforceable in the U.S., unless they continue to pay your salary (plus scaled increases based on past increases, if any were performance related) during the lockout period. You can thank my cousin for this, as he took his non-compete to the supreme court (and yes, they payed him to take the year off at his regular salary to prevent him from going to a competitor).
I think OP is trying to do the second one [...convince someone else to do it...] with this article. Perhaps someone will read this and be embarrassed enough to fix it.
Or perhaps it will backfire to discourage other people from posting future embarrassing articles every time someone has a problem where they consider a change a bug, and want the behaviour reverted?
A "shame the developer" post to Slashdot is not the same thing as pinging the developer directly, and makes this really undesirable to fix, as it implies that similar pressure would work on the same developer in the future. If I'm a volunteer, I really don't appreciate you making demands on my time with the threat of publicly thrown tomatoes to back up your demands should I not meet them in a fashion you consider timely.
It's also pretty ass to insist on a release schedule for a change (see previous post: what the OP wants is technically not a "fix", since it perpetuates inappropriate software layering) to software which is not normally released on a schedule, and which does not have specific changes preannounced until the code is actually done, since they may or may not make a particular release.
If you want that, with respect, you should consider running only Canonical releases, and buying a support contract from Canonical, or if you don't like that, make friends with someone else who has already bought one.
Read the bug report. The accessibility feature works. The submitter (who also happens to be the bug reporter) found a fairly minor subfeature (the ability for sticky key modifiers to act as lock keys) has been broken recently. I say fairly minor, because the only key this might be critical for in certain use cases is the Shift key, where a separate Caps Lock is already available.
The bug is asking for the wrong fix
Different modifiers have different combinatorial effects. Caps Lock is not necessarily Caps Lock, in other words. I know that most Linux people hate them because they are cheap, and you have to do a "disable secure boot" dance to install Linux on them, but ChromeBooks, in particular, lack a Caps Lock key. Caps Lock is achieved by hitting both shift keys simultaneously.
If that isn't convincing enough, consider Alt-Gr vs. Right-Alt behaviour on international keyboards that report a USB HID country code of 00h.
While I was working on ChromeOS at Google, there were a number of obvious usability issues for the OS, but the majority of them stemmed from the need to upstream support into Linux, and the difficulty of doing this without involving an Alan Cox, Ingo Molnar, or similar personage when you were dealing with things which crossed area boundaries. Input is one of these areas, and it was rather difficult and roundabout to get support for non-adjusted raw system time stamps in evdev inputs, even as a non-default option.
Exaggerating the issue by claiming it makes accessibility on Xorg unusable and bitching on slashdot because its been a whole 11 weeks since he found the problem and noone has released a fixed version yet is just grandstanding.
I agree the issue is exaggerated, but mostly because I disagree about where in the input stack usability issues should be addressed. The usability belongs in the input stack, as does the internationalization, below the point at which events are reported to the console, or to X (or Wayland or whatever display server is handling the apps and forwarding the input events).
It's pretty easy to see where this breaks down by enabling "programmer mode" (meaning: disabling "secure boot mode") on a ChromeBook, and enabling root or other console logins. It's easy to see the shift-shift (or Caps Lock, if you plug in a standard USB keyboard) and internationalized input don't work the same on the console as they do in the graphical environment.
In general, the input stack in Linux has a *lot* of problems. A fun experiment to try is plugging in 3 or 4 USB keyboards, and playing with the Caps Lock; the light goes on or off on whatever keyboard you're playing with it on, but the actual Caps Lock state depends on whether you've hit the Caps Lock key on an even or odd number of keyboards, and the keyboard Caps Lock lights very quickly become desynchronized from the actual Caps Lock state (i.e. turning Caps Lock on on keyboard A lights the light on A, and hitting it on B turns it on on B, rather than off on A, even though the state is that Caps Lock is no longer in effect).
Similar issues occur when using sticky modifiers for usability, and when moving between virtual consoles with various modifier/Caps Lock/etc. states in effect.
I understand the idea that you may wish to explicitly allocate resources in a multihead environment, but the input stack really doesn't do that very well, either - these modifiers should happen in the input stream above a stream join as a resource allocate by a virtual console or display server, and not in the display server or the underlying driver.
Windows doesn't support multihead well (at all, for multiple sessions, without something like Citrix intermediating the process), but it also doesn't screw up on where it put the internationalization translation tables and the dispatch routines and the usability.
PS: In case you care, AFAIK, there are zero vendors who put the correct internationalization keyboard code type in the USB
No. The map was made using existing data on known nuclear reactors and their power output and extrapolating what their antineutrino signature should look like. However, if geophysicists install detectors that show strong signatures that do not match up with the map given here, then that might be evidence for clandestine nuclear activity.
Yes. I see from the map that it's missing a number of known nuclear stations, for which the IAEA is unable to obtain data, and it's missing a number of "natural reactors" such as Oklu in Gabon, as well as a significant number of former Soviet reactors that are known to still be in use. It's also missing data for several Middle East reactors, known sites in South America, and a number of U.S. Military sites.
Assuming they get their experiment detectors running at all, they should be able to detect unreported nuclear reactor activity, but they'll have a hard time distinguishing it from the non-reactor related events they are seeking with the detectors.
You pay for access to the network of your provider and this has nothing to do with the provider - supplier communications.
Can I have another provider, then, please?
What do you mean "There's an infrastructure monopoly due to rights of way, and they won't let Google hang fiber optic cables on their telephone ples" ?
Don't these things sell a bit more slowly than MS predicts?
Not when Microsoft buys them from the vendors themselves, and then warehouses them. The problem is that old stock is removed from the front, and new stock is loaded in at the back, so unless they hit their predicted sales numbers, you get the older stock.
Microsoft just promised that they would ship (eventually); the only date involved is the date they made the promise, not a dealine by which the new stuff would be shipping exclusive of the old stuff, and certainly not the unsold stuff already in the channel.
What we have here is the use of an ambiguous generational designator that has nothing to do with the clock speed, and a journalist suffering sour grapes over not getting the faster model that has exactly the same description.
32 bit Office 2000 doesn't work on Windows 7.
Neither does it work on Windows 1.
Sure. And if we were talking about forward binary compatibility, which would require accurate predicting the future, that would be a valid argument.
We're not, we're talking about intentionally breaking binary backward compatibility, so that when you force someone to buy a new OS when they want to buy a computer, you force them to also re-buy application software, which they already own, to run on that OS.
This isn't any different than any other form of tying, where you leverage a monopoly in desktop OS's to force, for example, use of a particular browser. The money spent on Office 2000 is a sunk cost, and you're forcing them to re-spend.
I have just had a quick google and there are lots of posts claiming to have it working on windows 8 however, you are looking back five versions of office before you find one which does not work.
Please name another software vendor who provide this level of support.
Please name another software vendor with a monopoly in desktop operating systems, and I'll be happy to describe how they provide binary backward compatibility to avoid leveraging their monopoly position to force re-purchase of existing software by not tying that software to a particular platform.
I have read this a number of times and I can only assume you have never used a windows computer. The versions of office and windows are in no way restricted, I am running components form Office 2003, 2010 and 2013 on Windows 7 and Office XP, 2003 and 2010 on windows XP.
Windows Vista, 7 and 8 all have compatibility mode which tries with varying degrees of success to fool older pieces of software that they are running old versions of windows.
32 bit Office 2000 doesn't work on Windows 7.
You lost me at "unmanned". Enough said.
Further, Microsoft can support Windows XP, they just want more $$$ to do it (so, if they can do it for one company, and the goods they're selling are infinite, why can't they for all the rest?).
Actually, no. The reason they are willing to continue to provide the updates to some entities is because of the purchase and support contracts they entered into as part of a bulk purchase agreement. So they offer it not because they want more $$$, but because they are contractually obligated to do so. They'd just as soon give all these companies free updates to Windows 7 (or whatever) to get released from these contracts, which is the reason they are unwilling to extend support, for any amount of $$$, to other people caught in the same situation, but without benefit of contracts adding additional clauses on top of the clauses present in the public licenses themselves.
The paper (if you read it) claims that the requirement should be enforced based on the Microsoft having monopolistic power in the marketplace. Apple doesn't wield monopolistic power in the marketplace for desktop operating systems.
This is all a bit more subtle than that. The problem is; how do you define the market? When you go out and buy a computer and operating system in a shop, it's clear that Apple an Microsoft have a duopoly (which is a bit dodgy when you consider that they have cooperation on patents locking competitors out of the market; but we will leave that aside). When you come to look after your old computer that is no longer true. Microsoft will not generally provide OSs for Apple computers and Apple will certainly not willingly provide them for PCs.
That's not true. Microsoft will happily sell you Windows to run on anything capable of running it, and Apple went out of their way to support ACPI and SMP tables that are acceptable to Microsoft OS's, even though it required adding some substantial EFI modules, as well as providing driver support for Windows for Apple proprietary hardware.
Apple will certainly not provide Mac OS X for non-Apple hardware; however, this has been upheld multiple times in court cases as being acceptable because Apple does not wield monopolistic power in the desktop computer marketplace. Courts have led exactly the opposite in findings of fact when it comes to Microsoft.
In this instance, we define "market" as "market for desktop computer operating systems".
This means that, whilst Apple does not have a monopoly on computing in any way, they do have a monopoly on support for old Apple computers.
Agreed; however, the IRS amortization schedule on computer hardware is 5 years - and unlike Windows on PC hardware, Apple desktop computers consist of both the hardware and the software, not just the software running on white-box/grey-box machines. You could make the argument on the basis of hardware only for hardware sold with Windows installed, if it was considered part of the hardware. But again, we have court precedent forcing companies such as Dell and HP to offer white-box/grey-box hardware without the so-called "Windows tax", This means that the software is not subject to the same accelerated depreciation.
Specifically, IRS Publication 544, Chapter 2, under "depreciable business assets".
The correct answer would probably be that there is already competition in this market. By changing to a Linux os perating system you can maintain your 15 year old computer fully supported. Unfortunately, in many cases that's not true. Device manufacturers only provide full documentation and support to Microsoft and the Linux drivers cannot be guaranteed.
This is very much a red herring; while Open Source OS vendors and advocates, such as FreeBSD and Linux would dearly love for this to be the case, the problem is actually not with the platform, but with the capitol investment as a lump sum business asset, in software components, such as Microsoft Office and other components which can be assembled together with glue code to implement vertical market solutions.
Microsoft explicitly does not support Visual Basic, Visual Studio, Microsoft Access, or other software on non-Windows Platforms for the use model of implementing vertical market solutions (i.e. neither Linux nor FreeBSD nor Mac OS X have such support).
Further, the software packages of this type from Microsoft are tied to a specific version of the Windows Operating system; that is, you can not take a version of Office intended for use on Windows XP, and run it on Windows 7 or later versions of the Microsoft OS platform. This explicit and intentional tying is monopolistic in nature. Further, the glue code for the vertical market systems previously mentions, *also* will not run on non-XP platforms.
Effectively, this means that Microsoft is le
Personally, I think they are going about this the wrong way. The Gov't should be sending Death Squads to kill all members of any household still running XP, or running any version of IE less than 10. Brutal? Maybe. But, boy will it do wonders for the social lives of us Web Developers.
I might agree, if the versions of IE eligible for that treatment also included greater than or equal to 10...
I am a critic of M$ but I do not think they should be required by law.
Only in the case of some sort of long-term contract that is still in effect, that mentions specifically updating software until a time in the future...unless that is the case.
These laws are complex and the photocopier example is interesting.
A potentially more interesting example is replacement auto parts, which automobile manufacturers are required by law to stock for 10 years after the last date of manufacture so that owners of the vehicles can repair them or have them repaired by a third party. Since the last ship date for Windows XP was the last contractual date that Microsoft allowed vendors to bundle it with new computers, that would give them about an 8 year support requirement for "replacement parts". Note that the automobile example would apply to the GM ignition switch, which had an engineering change to correct a design defect - and any security flaw is technically a design defect.
I think that the more companies attempt to treat intellectual property as real property, the more that the negative aspects of real property law should be applied to their products.
E.g. if I use your patent, and you don't stop me using it, then I've engaged in adverse possession, and have "established an interest" in the intellectual property which you must therefore allow me to continue to use, just as if my driveway had been over the property line for 10 years, and you didn't do anything about it, or if I'd been parking my car at your curb, and it didn't bother you until I started parking my RV there and blocking your view.
The paper's argument seems to be along similar lines of thinking.
Photocopier vendors do not open the controller software up to competitors / vendors who provide support. They just give them specs for replacement parts.
Do you force Apple to let 'competitors' support OS X 10.5 on G5 Macs? Do you force Google to let competitors still support Google Wave?
The paper (if you read it) claims that the requirement should be enforced based on the Microsoft having monopolistic power in the marketplace. Apple doesn't wield monopolistic power in the marketplace for desktop operating systems.
If only it were possible to do challenge/response! Using a pre-arranged CERT, so that the drone sends a challenge for each command that has to be encrypted with the shared secret before the drone would accept it!
Oh... wait... it's completely possible.
You pick a platform based on market size.
It's not quite so simple, as you point out.
If you target one platform, you target PC's, unless the market for your application is graphic artists, musicians, etc., then you target Macs.
This is the important part. You don't target based on the number of devices sold--the market share--you target based on the platform that your intended audience is using.
Clearly, as an app developer, my intended audience is people with the willingness to part with money for my application, which is generally not the people who buy on the basis of price sensitivity.
But even foregoing that, if I develop for iOS, I basically have to tarket 7 platforms, while if I develop for android, I have to target many hundreds of devices instead.
Unless I'm Roxio, and my strategy is to own an app category on all devices, and I can afford it, due to an existing iPhone success, my ROI on developing for android is very low.
Can you identify a single market segment, other than "poor people who have no money to spend on apps" who would be interested in me developing my app for android instead of iOS?
You pick a platform based on market size.
PC's historically have had a lot more software available for them than Macs because you have a larger target market. If you target one platform, you target PC's, unless the market for your application is graphic artists, musicians, etc., then you target Macs. If you target two markets, you target PC's and Macs, and you don't target Linux.
If I target iOS because I have a product that will work on a tablet/mobile platform, then I have the largest possible market. I'm guaranteed a practically forced upgrade to the most recent version of the OS the platform can run, and I'm guaranteed that the device is going to have the same set of sensors and input methods as every other device.
I'm guaranteed that, even though it's not in AT&T's best interests, given their contract model, to not have the carrot of me not being able to run the latest OS unless I re-up my contract, I'm going to get the latest OS anyway, and screw what AT&T wants, and screw their business model, because that's what Apple wants.
For Android, I have to target a lot of versions of the OS; I practically have to target whatever the version was at the time they did the repo code freeze on the android sources, and started the platform port. I have to target different screen resolutions. I have to target different input methods. I have to target different camera capabilities, resolutions, directionality, and so on.
Practically speaking, each android device is an island. Some have a lager market share. If I wanted to target 6 platforms, 2 of them would be iOS, 1 of them would be iOS on iPhone 5 (different aspect ratio), and the other 3 would probably be Samsung Galaxy products (2 phones and a tablet, based on market share).
If you could resolve the android version difference problem, that'd go a hell of a long way toward making android competitive. It would require changing the android development model, and some of the partnership agreements.
Instead, Google is concentrating on forcing branding onto the boot screen, and forcing apps onto the device by default. The apps are a good thing, in general, since they tend to rationalize the user experience, but not the same way the VGA standard rationalized the user experience on PC's: minimally, there should be resolution and aspect ratio requirements for android - they matter a hell of a lot more to establishing an applications base than putting up a logo at boot time.
The walls on Google's walled garden are also rather porous. They are more "We won't let you play with the toys we have" rather than "we will keep the bad guys out". And it shows. It shows that other people can run android app stores, that they do, and that there's a huge amount of malware out there in those place. They show in the balkanization of the market by OEM vendor stores, and by carrier stores.
It's crap that I can buy an iOS device, and get "The Apple Experience" - a uniform thing across all the devices - but that I can't buy an android device and get "The Android Experience" - unless you call a balkanized chaos "The Experience".
So yeah, as a developer, I don't target android unless I'm Roxio and have more money than God to spend on programmers for platforms where I'm going to end up selling 50 copies of the game that everyone has, and then sell follow-on modules on a monthly basis until the cows come home, in order to monetize that investment over a long (I don't care how long; I'm not living hand to mouth, I'm Roxio!) period of time.
So yeah, android has shit apps. Make it a uniform platform, instead of me trying to develop for the Mac and the Apple IIe and the Ohio Scientific, and the Orange Micro, and the TI-99/4A, and the Timex Sinclair Z-8000, and the Tandy CoCo, and the Wang word processing station, and the ... or keep your balkanized mosaic of "Choice, man! Yeah! Choice!" and write your own damn software.
The problem is that this is still a "success story".
If the success story earns slightly above average, then you probably don't want to know what the average earnings are.
I'm somewhat confused. Yes, it's a success story; how is that a problem? How is it an example of the OP's thesis? How is it in any way applicable to the OP's thesis, given that his thesis involves college students, and these students were, at the time of their success, 2-3 years away from making a decision in that regard?
$30 an hour is shit for good programmers. I earn over double that as base and have full benefits.
$30 an hour is actually fantastic for these kids.
They're not good programmers, they're high school sophomores, one is barely old enough to get a restricted drivers license, they don't have enough formal education that they wouldn't be lost in a team meeting where "big-O" notation or "trie" were mentioned, and they wouldn't be able to communicate with their peers effectively, even if it was just over email to avoid the whole ageism thing.
That's $62,400 per year, and even if we split that between two of them, that's $31,200 each, which is 25% more than the college interns with three years of college toward a CS degree were making.
And even divided, it's higher than the starting salary of a public school teacher with a masters in education (because it's required to get the job and the teachers union membership) in the San Francisco Unified School district.
$30,000 / 1000 = $30 an hour. Just saying.
Well, the obvious answer is "move to California"; California courts have invalidated out of state non-competes former employers in other states have attempted to enforce against workers in California.
Practically speaking, unless there's an arbitration clause or a venue clause in the non-compete that sticks it to Massachusetts, there's really very little the employer can do. The recent Atlantic Marine decision on the venu clause strengthens somewhat the requirement that it be part of the signed agreement at the time.
Thank you, I've always wondered why these types of waste were not reprocessable. A friend of mine went to ASU in the '70s/'80s and they had an Indian physicist called Dr. Roy (no idea what the last name was) who claimed to have a method for safely disposing of nuclear waste, never heard of the program going live.
France doesn't have a use for the plutonium because they do not run a sufficient ratio of Pu reactors or breeders to produce the Pu to fuel those reactors.
This was France's answer to the "nonproliferation problem" which Jimmy Carter dealt with by disallowing reprocesseing in the U.S. altogether; this ban has been lifted, reinstated, and lifted again, but in general, it's not worth building something over the period of a decade if it will potentially end up banned again. So we have a plant, we only have a couple DOE operated breeder facilities for weapons grade materials, and the commercial reprocessing plant that was recently just mothballed.
Most of the problems at this point are political, and most of the costs are either protest-driven or redesign-the-plant-while-building-it-driven rather than actually technical.
No one at being recruited is at will. These aren't tech support jobs they're design and engineering teams. These folks have very detailed contracts. Your not working a new products without one.
You're quite wrong. Having worked on secret projects at both Apple and Google, the only thing you get to sign extra above and beyond your original employment agreement, which is primarily a non-disclosure agreement, is layered non-disclosure agreements.
It's actually quite funny, since they bring you an agreement with a project codename on it that you aren't allowed to discuss under your original agreement, and then after that NDA, you are now allowed to learn the codeword for the project you're going to be working on, and you sign an NDA for that project, too.
Very, very rarely you will be asked to sign a vendor or partner NDA, but if you're asked to do that, you are generally compensated for the signing, because it means not working in that area for another company for a couple of years, and the compensation is to pay you for foregoing the opportunity.
FYI, everyone below management director level, including line managers, are "at will", at least in Apple and Google in California, and it's likely the case elsewhere, since some of the work is considered by the Franchise Tax Board to take place in California, if you are managed from California, so California gets to collect income tax on it. The two "Distinguished Engineers" I know at Apple I've discussed it with are also "at will", rather than contract employees.
I'm not sure about the people at director level or above at Apple, or above directory level at Google, since, frankly, the topic has never come up in casual conversation, and generally people tend not to talk about their compensation anyway, unless you are a very close friend or family member.
Generally, both companies rely on options maturation (or RSU - Google calls them GSUs and ties them to performance) vesting schedules to act as "golden handcuffs", rather than contracts. You're generally not a high level contract employee without a parachute (silver or golden).
In case you are wondering, non-competes are also not legal in California, unless the competition occurs as side work during your employment at the company, and generally are not considered legally enforceable in the U.S., unless they continue to pay your salary (plus scaled increases based on past increases, if any were performance related) during the lockout period. You can thank my cousin for this, as he took his non-compete to the supreme court (and yes, they payed him to take the year off at his regular salary to prevent him from going to a competitor).
I think OP is trying to do the second one [...convince someone else to do it...] with this article. Perhaps someone will read this and be embarrassed enough to fix it.
Or perhaps it will backfire to discourage other people from posting future embarrassing articles every time someone has a problem where they consider a change a bug, and want the behaviour reverted?
A "shame the developer" post to Slashdot is not the same thing as pinging the developer directly, and makes this really undesirable to fix, as it implies that similar pressure would work on the same developer in the future. If I'm a volunteer, I really don't appreciate you making demands on my time with the threat of publicly thrown tomatoes to back up your demands should I not meet them in a fashion you consider timely.
It's also pretty ass to insist on a release schedule for a change (see previous post: what the OP wants is technically not a "fix", since it perpetuates inappropriate software layering) to software which is not normally released on a schedule, and which does not have specific changes preannounced until the code is actually done, since they may or may not make a particular release.
If you want that, with respect, you should consider running only Canonical releases, and buying a support contract from Canonical, or if you don't like that, make friends with someone else who has already bought one.
Read the bug report. The accessibility feature works. The submitter (who also happens to be the bug reporter) found a fairly minor subfeature (the ability for sticky key modifiers to act as lock keys) has been broken recently. I say fairly minor, because the only key this might be critical for in certain use cases is the Shift key, where a separate Caps Lock is already available.
The bug is asking for the wrong fix
Different modifiers have different combinatorial effects. Caps Lock is not necessarily Caps Lock, in other words. I know that most Linux people hate them because they are cheap, and you have to do a "disable secure boot" dance to install Linux on them, but ChromeBooks, in particular, lack a Caps Lock key. Caps Lock is achieved by hitting both shift keys simultaneously.
If that isn't convincing enough, consider Alt-Gr vs. Right-Alt behaviour on international keyboards that report a USB HID country code of 00h.
While I was working on ChromeOS at Google, there were a number of obvious usability issues for the OS, but the majority of them stemmed from the need to upstream support into Linux, and the difficulty of doing this without involving an Alan Cox, Ingo Molnar, or similar personage when you were dealing with things which crossed area boundaries. Input is one of these areas, and it was rather difficult and roundabout to get support for non-adjusted raw system time stamps in evdev inputs, even as a non-default option.
Exaggerating the issue by claiming it makes accessibility on Xorg unusable and bitching on slashdot because its been a whole 11 weeks since he found the problem and noone has released a fixed version yet is just grandstanding.
I agree the issue is exaggerated, but mostly because I disagree about where in the input stack usability issues should be addressed. The usability belongs in the input stack, as does the internationalization, below the point at which events are reported to the console, or to X (or Wayland or whatever display server is handling the apps and forwarding the input events).
It's pretty easy to see where this breaks down by enabling "programmer mode" (meaning: disabling "secure boot mode") on a ChromeBook, and enabling root or other console logins. It's easy to see the shift-shift (or Caps Lock, if you plug in a standard USB keyboard) and internationalized input don't work the same on the console as they do in the graphical environment.
In general, the input stack in Linux has a *lot* of problems. A fun experiment to try is plugging in 3 or 4 USB keyboards, and playing with the Caps Lock; the light goes on or off on whatever keyboard you're playing with it on, but the actual Caps Lock state depends on whether you've hit the Caps Lock key on an even or odd number of keyboards, and the keyboard Caps Lock lights very quickly become desynchronized from the actual Caps Lock state (i.e. turning Caps Lock on on keyboard A lights the light on A, and hitting it on B turns it on on B, rather than off on A, even though the state is that Caps Lock is no longer in effect).
Similar issues occur when using sticky modifiers for usability, and when moving between virtual consoles with various modifier/Caps Lock/etc. states in effect.
I understand the idea that you may wish to explicitly allocate resources in a multihead environment, but the input stack really doesn't do that very well, either - these modifiers should happen in the input stream above a stream join as a resource allocate by a virtual console or display server, and not in the display server or the underlying driver.
Windows doesn't support multihead well (at all, for multiple sessions, without something like Citrix intermediating the process), but it also doesn't screw up on where it put the internationalization translation tables and the dispatch routines and the usability.
PS: In case you care, AFAIK, there are zero vendors who put the correct internationalization keyboard code type in the USB
No. The map was made using existing data on known nuclear reactors and their power output and extrapolating what their antineutrino signature should look like. However, if geophysicists install detectors that show strong signatures that do not match up with the map given here, then that might be evidence for clandestine nuclear activity.
Yes. I see from the map that it's missing a number of known nuclear stations, for which the IAEA is unable to obtain data, and it's missing a number of "natural reactors" such as Oklu in Gabon, as well as a significant number of former Soviet reactors that are known to still be in use. It's also missing data for several Middle East reactors, known sites in South America, and a number of U.S. Military sites.
Assuming they get their experiment detectors running at all, they should be able to detect unreported nuclear reactor activity, but they'll have a hard time distinguishing it from the non-reactor related events they are seeking with the detectors.
http://www.gpstk.org/bin/view/...
http://www.rtklib.com/
http://gnss-sdr.org/
Next time do your own google search.
The batteries last too long!
Quick! Add more electroluminescent wire! Hurry Robin, the the Maker Faire!
You pay for access to the network of your provider and this has nothing to do with the provider - supplier communications.
Can I have another provider, then, please?
What do you mean "There's an infrastructure monopoly due to rights of way, and they won't let Google hang fiber optic cables on their telephone ples" ?
Don't these things sell a bit more slowly than MS predicts?
Not when Microsoft buys them from the vendors themselves, and then warehouses them. The problem is that old stock is removed from the front, and new stock is loaded in at the back, so unless they hit their predicted sales numbers, you get the older stock.
Microsoft just promised that they would ship (eventually); the only date involved is the date they made the promise, not a dealine by which the new stuff would be shipping exclusive of the old stuff, and certainly not the unsold stuff already in the channel.
What we have here is the use of an ambiguous generational designator that has nothing to do with the clock speed, and a journalist suffering sour grapes over not getting the faster model that has exactly the same description.