Except that the last update to the software was more recent than 20 years old. It occurred at least a recently as 1993. Obviously a universal binary would have been worthless, but my reply was simply a reply to the parent, which was talking about how even for a programmer attempting to compile source code is not as easy as it it seems like it should be.
No my reply was strictly a reply to the parent post. Even programmers find compiling to be a pain, especially if software is not pre-ported. I really don't see universal binaries as very valuable at all, given that they don't help with the porting. Once source is ported there is no reason for the porter or maintainer to ever compile for that platform again. Just create an auto-compilable source package. Gentoo is the ultimate example of that, but even the vast majority of binary packages for Debian architectures are auto-built from source.
Perhaps if LSB were working well enough that all x86 GNU/Linux distros could run the same version of an app, and all PPC GNU/Linux distros could run the same version of an app, a universal binary might be something a proprietary vendor for Linux might like, since it would ensure all users got a version that would work on their architecture (if theirs is supported at all) rather than accidentally downloading/ordering one for a different architecture.
Bobbs-Merill v. Straus Is not directly applicable. A very important quote from the ruling: " There is no claim in this case of contract limitation, nor license agreement controlling the subsequent sales of the book. In our view the copyright statutes, while protecting the owner of the copyright in his right to multiply and sell his production, do not create the right to impose, by notice, such as is disclosed in this case, a limitation at which the book shall be sold at retail by future purchasers, with whom there is no privity of contract."
The court did not rule that it was not possible to license a book, but merely that a notice printed in the book does not cause a license to come into existence out of mid air.
Had the copyright holder had in place contracts with the wholesalers to only sell the books to retailer who accepted the terms to sell the book at no less than $1, the court may have ruled differently.
However some later cases may actually be applicable, and it would not surprise me if they made it almost impossible to license a book in a way similar to EULAs.
Nevertheless it is most definitely possible to license a book, in which an owner maintains legal title to the book but possessor has rights to use the book. Indeed this is done often enough in some circles, but in those cases the way one acquires the license is usually very different from the retail shopping experience, and often involves contracts signed by both parties, and may even not be contracts of adhesion, allowing negotiation of terms. In the case of software licensed in a similar way, nobody really thinks the License may not be applicable.
EULA's are slightly different and there are are the clickwrap EULAs, which may be legally different than the inside the box EULA's which in turn may be legally different than the Written on the Box EULAs. The law here is about as far from settled as is possible, and what is really needed is a supreme court decision that chooses to decide the matter for all possible cases, rather than just the specific case at hand. Unfortunately the supreme court usually chooses to not to be so sweeping, so sweeping decisions are generally a side effect of the use of specific logic in a decision that has not be fully limited to the specifics of the case at hand.
The problem is that many companies see no problem with paying RAND patent fees, and fail to see why that would make it not open. The is especially true in areas where patents are pooled, so if you have even one patent that might apply you add that to the pool, and either get a partial refund on the fees by being part of the pool, or having the fees waived entirely. (Depends on the specific patent pool).
Also what is an Open Specification? Is it one that is publicly available without fee? In that case the C programing language would not be an open standard, nor would many other ISO or IEEE standards that we all take for granted. (Admittedly some of those standards also have freely available standards that are effectively equivalent or even superior, like PDF, where the ISO standard is a subset of full PDF, or PNG where the ISO standard should be equivalent to the PNG specification).
Yes and no. As far as I know windows style guidelines don't emphasize these ypes of features very much. They are also not very visible in the bul-in applications that come with the OS, while for example the common dialogs for file oipening and closing are. If the OS's built-in applications supported saving only by dragging to a folder for example, then that would become very obvious, and other applications would be sure to support it. If the only way to print was dragging a file or content to a printer icon, or if that meathod was shown in the built-in OS video tutorials, then it would be more likely to work in most applications.
If Microsoft was to to write to makers of the textbooks and state that dragging to the printer icons was the preferred method of printing in Windows 8, and requesting that this be the meathod emphasized, then application would follow along.
OS Paradigms like these are as much a function of support by most software as support in the Windows Manager, core libraries or kernel. If most mac app developers did not make sure that their applications could run from any folder, then that paradigm of MacOS, that apps are icons that can be put wherever desired and run from there would fail to be a MacOS paradigm.
True, but only in very limited ways. I just dragged a PDF file to my printer and it worked fine. The Acrobat program opened and closed visibly, but otherwise it just worked. I tried to drag a.cxx file to the printer (.cxx files are associated with Visual Studio on my system, as it is the only IDE on my system, even though I'm more like to compile a program with gcc and idit it with emacs) and I get message telling me that the program only supports printing to my default printer, and asking me if i want to change my default printer. That is obviously nonsense.
Worst of all was trying to drag a.docx file to the printer. The net result of that was that some other document I already had open in Microsoft Word 2007 being broaught to the front. Nothing was printed, no print dialog opened, the file in question was not opened, nothing.
Draging file to programs works reasonably often, but not always, sometime the program attempts to embed the file in the document I'm working on instead. Dragging to a folder is quite hit and miss. I just tried that with a PDF, and was surpsied to see it create an rtf file with the desired content in it. I did the same with the part of a word document and it decided to add it to my desktop as an Active Desktop item. A piece of short lived technology from windows 98, that had just enough demand behind it that Microsoft apparently ported it to XP. So I try again with a different part of the document, and it resulted in a "scrap" file, which is an old and long abondoned peice of Microsoft technology created back when OLE was first really coming out, intended for exactly that soft of purpose, but quickly abandoned by virtuall all products, except Office, since somebody may reply on that functionality.
Further in Windows all of these even when they do work are alternatives to the traditional flow, not replacements for them.
"What I'd love to see happen with the Linux desktop is some serious re-thinkng of how a UI should be done."
Hear Hear! Yes, I too am a little disappointed that the "zenith" of Free Software seems to be cloning the look and feel of Windows, which is cloning the Mac, etc.
What about some real ground-breaking stuff - how about a marriage of GUI and Unix-y pipe goodness, where you could connect applications together in a GUI and have them do data flow type work - take the Unix filters approach one (or more) steps further?
What about getting RID of the file selector, and just using the normal file views + drag and drop to open and save files? Drag a file to your word processor, and it opens. Drag the tab from the word processor to a disk, and you save. Drag a section of a file, and you save that section. Drag that section to the desktop, and you save a cut buffer, and you can have as many cut buffers as you want.
Hell, why can't I just drag a file to a printer icon to print it? Why do I have to OPEN the file, then print it?
Somebody correct me If I'm wrong, but it sounds to me like you were just describing Plan 9 at the GUI layer.
I believe I remember reading that the desired UI paradigm was that save as worked by opening a window with an icon, what you dragged wherever you wanted the file to be. This was back before tabbed interfaces became common enough that the just dragging the a tab and dropping it resulting in a file made sense. There was no save dialog. equivlently one could just drag the dogument to the printer to print it, or to another application to open it without ever committing it to disk.
I cannot find a source for this now, so perhaps it was another fairly esoteric OS.
While this may be true, some micro-scale evolution strongly appears to have occurred in the past 200 or so years. Looking at old presidential portraits back in high school, I noted that quite a few of our earlier presidents had rather distinctive facial features in common, which are almost never seen anymore. Some of them were not only downright ugly by modern standards, but looked downright creepy. Now, I'll admit a few of them just may have had bad portraits, but there were too many of them for that alone to be the issue. I also find it almost impossible to believe that the differences are due to things like plastic surgery, since some of those feature's I've never seen on a real person, except when they had significant hollywood makeup applied to artificially create that feature.
2 cm is considered a reasonably significant height difference, but a shift of 1 kg in mass? Even people who have roughly "correct" mass (neither over-mass nor under-mass) can shift by 1 kg in a single day.
If every women in the country magically gained 1 kg tonight, most people could not even tell that this had happened. Yes, the extra mass might be noticed on some people, but on quite a few people the change would be almost impossible to detect without measuring. You really need shifts of around 2-3 kg before a difference could be reliably detected visually on the vast majority of "correct"-mass people. (Obviously on a morbidly obese woman, even 5 kg may be difficult to detect visually, while even minuscule changes on significantly under-mass women are likely to be noticed).
For the fellow US readers: 1 kg is approx 2.2 pounds, and 2 cm is only ~0.7 inch.
So that would be like a Microsoft hiring somebody to fix bugs after he showed he was able to find and exploit many of them by searching though one of the periodic Windows Source Code Leaks? Sounds possible, if the exploiter clearly did not have malicious intent, which these days would be much harder to show, since exploiting Window bugs is not likely to result in free internet access or the like.
Sure, but aren't finical systems using fixed point data types just about everywhere? Additonas and subtractions are the most common operations on fincial numbers as far as i know, with the next most common operating being mutliplications/divisitons within a limited range of values (that is multiplications by more than 1000 are rare, as as multiplications by less than one thousanth are also rare.) Seems fairly ideal for the use of fixed point representations. If floating point representations are used anywhere in a finacial system, I'd hope they would be BCD encoded floating point operations, as the various rounding errors encountered in the use of such a system generally match human expectation fairly closely, since they generally match the types of rounding errors found in doing the same calculations with paper and pencil.
Yes. The issue here sounds like they had a system clock counter that was an integer, that counted the number of 0.1 second clock ticks. Then they wanted to convert this to a floating point number in 24 bit IEEE format, They simply multiplied 0.1 by the integer in the register. Of course, that still sounds like too large an error top have occured from just that, but lets pretend it did.
There are several issues here. For missiles travelling at such speeds, using a system clock counter based on 0.1 second ticks sounds terribly coarse to me. Second, since 0.1 seconds are the baseline resolution of the system, the system should have been using floating point numbers where '1' corresponds to a decisecond rather than a second. Then the time counter would be exactly expressible in the floating point format.
Lastly, if the floating point format really needed to be in units of seconds, rather than deciseconds, the time counter should have been loaded in, having an exact representation, then it should be divided by 10, which has an exact representation. This is all prety basic to anybody who has even a limited understanding of floating point. If you understand the inherent precision of every operation even better than I do, even more improvements would be possible.
But to be honest, I'm not sure why floating point was used at all here. It sounds to me like fixed point may have worked just fine for most of these problems. (Of course, fixed point has its own set of rules ensuring maximal accuracy. )
True. A truely basic GPS system provides time and location information, (and velocity information too generally), but that is all. Technically for some purposes that is all that is needed. Geocaching could in theroy be done with such a device, although a more feature complete one is better.
Supporting waypoints, and rlative positioning is the next step, and any small device with some form of serial port (be it a real one, serial over USB, Serial over bluetooth, etc) can provide this level of functionality, most would have absolutely no problems providing very coarse grain maps. (Edges of states/countires showing up, etc). But for many uses much higher resolution is desired. At the very least, high resolution mapping is desired. In some cases, like the Google Earth applications, even areal photos are useful. (I strongly suspect that a phone with with GPS and Google Earth are far more useful for some off-road activities than traditional GPS units are, at least if network connectivity is available. Data about roads and speed limits, etc are just no of that much use.)
But for vehicle navigation, full mapping data with roads and connection information, and many waypoints for things like gas stations, and resaurants are almost essential. And those are fairly large. Not many devices can natively fit a full data set, and manufactures long ago realized that requiring users to download up to 3 out of ten regions at a time, or similar is just crap. One option then is streaming data over the internet.
Now Full mapping data for a country like the United States fits well on an SD card, and I suspect using an SDHC card, full mapping data for the EU+(Switzerland) could be put on a card. I know that Garmin devices in theory can support having full mapping data for the planet split between the build-in memory and the SD card, if the SD card was large enough, and the owner was willing to pay for all the maps. Garmin even sells maps on SD card (Writable SD cards, not the rarer SD-ROM cards that are possible but virtually never seen.)
So I'd say the real threat to standalone GPS's would come from Cell applications that use map data from an SD card. I'm not sure if any of the major GPS manufacture's applications for any phone model support using the same maps from the stand alone devices on SD cards, but that would be far more of a true threat to stand alone devices than Google's new android application.
These people aren't going to buy the DSi, both because unlike the DS Fat to DS Lite transition the new console isn't clearly better for their needs (the Lite's screens were much better, and it was actually pocketable), and because they resent the upgrade treadmill.
Very true. Let's look back at the Nintendo Handhelds from the beginning.
Game and watch. Simple, but they played only one game.
Gameboy. A reasonably versatile little platform. It was not as powerful as some rivals, with only mono speaker (but stereo headphone support), had only four shades of grey on the screen, and required four AA bateries.
Next up we had the Gameboy pocket. Based on the next generation of circuit components, this was much smaller than its predecessor, and provided similar battery life using only 2 AA batteries, but was otherwise similar. There was no reason to upgrade existing Gameboys unless the changes interested you. To the best of my knowledge it was not possible for a game to detect the difference between the two in any supported manner (although information may have leaked from some timing edge cases.)
The Gameboy lite was an interesting upgrade that came next, but was japan only. Once again from the game side, this was identical to the original gameboy.
The Gameboy Color was the first one different from game's perspective. This one would be a necessary upgrade to play some of the latest games, but had perfect backwards compatibility, and supported games that would run on the original with additional pallet information or even additional features on the GBC. The full feature set was available in GBC only games. In theory, a color/regular cart could have used all the GBC's features when available, but only a subset was used, specifically, double speed mode and full set of pallets was not used, as those could not be used with only simple branching to skip the GBC only parts on the original GB, so code path duplication would be needed. Also any well made GBC only game would still run on the original GB, if you could get in in the cartirdge slot, but would simply display a warning that the game was GBC only.
Nobody complained about the GBC too much, because it was a definite upgrade from the old system.
Next we got the GBA. Once again a definite upgrade so there were few complaints, although the backwards compatibility was a bit less then it could have been, with a few games having small issues, and the lack of the GBC's IR port. The shoulder buttons, larger screen, and significant processor improvements made this a much better machine than its predecessors.
We get the GBA-SP. The biggest complaints here were about some flaws in the GBA-SP itself, like no headphone port without adapter. It was completely compatible with the GBA, and the difference could not be detected in software. People generally did not complain because there was no reason to upgrade unless you wanted the light, or built-in rechargable battery. The old ones worked just fine for everything.
--------------------
Now we reach the end of the traditional upgrades where there were few to no complaints. most were either optional, being indistinguishable from software, or were significant improvements. Backwards campatibility was lacking a bit, in a few spots, but only with a really small number of games, or if
We get the DS. This is introduced as a third prong, and dropped backwards compatibility with everything but the Gameboy Advanced. The GBA games had pretty good compatibilily, but slightly worse than the GBC->GBA transition, and the lack of support for link cables was a real killer. So it should not be viewed as a GBA replacement, but a new console with the possibilty to play some old games, communicate with old games though editing the game's savefiles, or use the second port for expansions.
The DS-lite came out, to only limited complaints, most about the GBA carts and accessories sticking out. It was fully compatible with the existing DS in both directions
Just the other day I tried to compile Berkley SPICE for under Linux. That was a real pain in the ass, since it apparently not only predates Linux, but it also predates ANSI C and POSIX being wide-spread enough to depend on them. By default it assumed that void* pointers where not available, so it used char* pointers, unless a specific #define was used, in which case some but not all of the erroneous char*'s were converted to void*. It made incorrect assumptions about what header files included a function (relying on header files implicitly including other header files when they are not required to), in some cases, bypassed including header files, and just added extern function declarations. Since this was K&R C the function declarations (prototypes) did not list the arguments, but they still managed to use return types different from those specified in POSIX. And in a few cases, the arguments passed were of the wrong type because apparently they were specified differently in early UNIX.
That is not counting the places where a function returned a local array, rather than a copy of the array. (In fairness, the author did comment this asking if it should have been returning a copy instead.
Some of the function names conflicted with those used in C99, which they obviously could not have predicted, but did mean I needed to compile with "-std=c89 -posix", which took me a little while to realize. Etc.
So despite the code being targeted at a Unix, it took me several hours to compile it for Linux. This just goes to show that porting can be a real pain, and end users should not be required to compile programs themselves. Now, locally compiling programs can be a valid install strategy, as seen in Gentoo, but a ported must have checked on each targeted platform that the code compiles as-is, or provided patches if needed. It also is a pain if the system you are installing on does not have compilation tools for some reason, such as being an embedded system with limited space.
The simple fact of the matter is that most of these industires are locked into a model that made some sense back when it was started. Regional versions of products often made sense because of either local requirements (Different line voltage and frequency) different safty regulations, and the fact that not long ago it was prohibitively expensive to import something on a one off basis, and still for most items, ording from overseas can be pretty expensive, but still potentially viable for a consumer.
So in may industries we got a developer/designer, potentially a separate manufacturer, importers, distributors, etc. Creative efforts often had a separate producer too.
Content like television had a modified version of this model, where exclusive complete exploitation rights for some franchise in a limited geographical area is sold to another company. Producers often completely lack the rights to authorize sites like Hulu to show content outside the US, since they sold those rights already. Back when these sorts of deals first came out, this was because the producer would find it very difficult to negotiate broadcast agreements with channels overseas. There were just too many, with language barriers, and limited communication speeds. Under such a system both parties had something to gain. The regional rights holder could negotiate broadcast agreements with much more ease, and get profit through this. The production company would get revenue from overseas broadcasts which woiuld otherwise simply not not occur.
The model has become so entrenched, that I'm not sure that a production company could possibly keep enough rights to authorize international streaming, while still getting the shows aired overseas, since channels overseas are used to dealing with local rights holding companies when negotiating for broadcast rights, and would be reluctant to negotiate the rights directly with the producers, if they even are allowed to, by the contracts they have with the local rights holding companies. In this day and age, it is far more feasible for a producer to directly negotiate broadcast rights with overseas channels, so the benefit to them of the international rights holders have diminished greatly, but they are still around.
In the modern age of globalization and global connectivity, political borders should have little meaning when it comes to products or content, but many industries are locked into the old models, with little hope of changing in the short term. There are no few to no gentlemens agreements here, mostly just shortsightedness on the parts of many parties, and quite a few binding contracts where the the company with exploitation rights is not willing to let the contract be withdrawn. (As they now clearly have the better end of the deal, while originally the deal was fair or perhaps in the other direction). Combined with the existing system being so entrenched bypassing it is almost impossible, we get the nasty mess that we have.
Yes, distribution information is needed, or a measure that takes distribution into account is needed for the numbers to mean much.
Since we are working with a sample of the human population, if we were hopping to know the correlation in the population as a whole (which is probably more useful than the correlation in the particular sample), we would want a rho value range for some confidence interval, although admittedly getting a rho value for the particular sample in question is a necessary first step.
The social security numbers were just a way of having people choose completely arbitrary non-biased numbers as a base price to make a buy/don't buy decision against. Credit card numbers or phone numbers could have been used instead, or even assigning each person a completely random two digit number. The whole matter is that once they make a decision at some price, it appears that this is fairly likely to influence the price they would bid for it in an auction.
Since the initial price consideration is arbitrary and random, a shared previous cause (or influence) of both the initial decision price, and the bid price can be ruled out with high confidence. The bid price causing or influencing the initial price is similarly all but impossible. That leaves either the initial decision price causing or influencing the bid price, or the correlation found being a mere freak occurrence.
You are exactly correct. AIUI, as long as he is free to exercise the four freedoms, rms is happy. He sees nothing at all wrong about offering software in a dual-licensing scheme like this. I suspect he feels that in a perfect world nobody would ever choose to use the proprietary license option, but that there is no harm in offering it.
Harm may come if somebody uses the proprietary license to create another proprietary application without a similar dual-licensing system, but that would be the fault of developer of this new application, rather than being the fault of original application/library developer.
My description is a big room, with a blue or or gray ceiling; malfunctioning lighting, sprinklers, and climate control; and severe problems with the air not remaining stationary at times.
Although to be fair, some slates come with small detachable keyboards that can be left in placed and pivoted around like on the laptop/tablet hybrids, giving you the choice of having an omnipresent keyboard at a cost of a little additional thickness, or not at your choice, by leaving the keyboard behind. I like that system. I image I would normally leave the keyboard attached, but I still see it as fundamentally different than the swivel screen "tablets".
Perfectly logical to have a central repository for everything. That way when Palm decides it does not want to support the phone anymore, or it goes out of business, the phone effectively becomes worthless, unless there is some way to bypass both the store, and the hosting by palm, and still be able to install software on the device.
At least with Apple, I can be reasonably confident that the company will remain around for a while, and that the App store will be there for many, many years in the future.
Given Palm's history I'd not be confident on either front.
I fully understand why regular images are left out. But leaving out the latex images is much more of a problem in many articles. The file size of those images, is surely only a small fraction of the total file size of all the images used in articles. The latter is obviously way too large for a small device.
But I've no idea what the cumulative size of the LaTeX images is so I have no idea how viable including them premade is.
The LaTeX images definitely can in theory be generated on demand, at the cost of adding quite a bit of complexity to the mobile Wikipedia implementation.
I agree that on a device like the iPhone/iPodTouch the correct way to handle external links is to launch the browser. On other devices, like the one in the article, the correct way would probably be to show the full url when the link is clicked, so it can be entered into a web browser on some other device.
Signing a petition does not mean that you agree with the views of the petitioner, it just means that you agree that the issue should be brought to a wider vote to decide the matter. I've known plenty of people who would sign pretty much any referendum or initiative in the states that have that process. In their view, it just airs more discussion and opportunities for democracy.
That may the biggest issue of all.
Is it completely implausible that some of the petition signers actually support gay rights, and were pretty confident (perhaps naively) that if it came to a vote, allowing same-sex civil unions would be upheld, making the matter settled?
The assumption that all signers actually supported ending same-sex civil unions is the real problem. If the website in question gave that impression, then defamation lawsuits (or perhaps even libel lawsuits) may be fully justified.
Wacom makes an oversized multitouch trachpad call the bambo touch. Priced at $69 dollars it is a little expensive, although there is a $100 version that also works as a wacom digitizer tablet, which is a pretty good deal in my opinion.
The normal touchpad controls apply, including the standard tap-and-half to drag, (although there is also a multitouch gesture for dragging, which is probably more convenient, and also works for clicking too). It includes the standard zoom and rotate multitouch gestures, as well as the swipe right and swipe left gestures for forwards and back. It also features a right click multi-touch gesture (two finger tap), and scrolling gesture, (two fingers sldining smoothly up and down, or left and right ((it is not specified, but also probably a mixutre of the two).
I'm not sure if the apple trackpad offers any additonal gestures, but if this interest you, you cnan check out the manual at http://www.wacom.eu/_bib_user/dealer/man_bampt_en.pdf (the US site still has the manual for the older versions lacking touch support), and can find more details about the product at www.wacom.com, including the ability to purchase online.
The tablet is fully compatible with Windows and Macs, although the Linux drivers have not yet been updated to support it. The Linux drivers are developed by a third party, using Wacom internal documentation provided under NDA, so it is only a matter of when, not if it will be supported.
Slashdot Mirror
Except that the last update to the software was more recent than 20 years old. It occurred at least a recently as 1993. Obviously a universal binary would have been worthless, but my reply was simply a reply to the parent, which was talking about how even for a programmer attempting to compile source code is not as easy as it it seems like it should be.
No my reply was strictly a reply to the parent post. Even programmers find compiling to be a pain, especially if software is not pre-ported. I really don't see universal binaries as very valuable at all, given that they don't help with the porting. Once source is ported there is no reason for the porter or maintainer to ever compile for that platform again. Just create an auto-compilable source package. Gentoo is the ultimate example of that, but even the vast majority of binary packages for Debian architectures are auto-built from source.
Perhaps if LSB were working well enough that all x86 GNU/Linux distros could run the same version of an app, and all PPC GNU/Linux distros could run the same version of an app, a universal binary might be something a proprietary vendor for Linux might like, since it would ensure all users got a version that would work on their architecture (if theirs is supported at all) rather than accidentally downloading/ordering one for a different architecture.
Bobbs-Merill v. Straus Is not directly applicable. A very important quote from the ruling: " There is no claim in this case of contract limitation, nor license agreement controlling the subsequent sales of the book. In our view the copyright statutes, while protecting the owner of the copyright in his right to multiply and sell his production, do not create the right to impose, by notice, such as is disclosed in this case, a limitation at which the book shall be sold at retail by future purchasers, with whom there is no privity of contract."
The court did not rule that it was not possible to license a book, but merely that a notice printed in the book does not cause a license to come into existence out of mid air.
Had the copyright holder had in place contracts with the wholesalers to only sell the books to retailer who accepted the terms to sell the book at no less than $1, the court may have ruled differently.
However some later cases may actually be applicable, and it would not surprise me if they made it almost impossible to license a book in a way similar to EULAs.
Nevertheless it is most definitely possible to license a book, in which an owner maintains legal title to the book but possessor has rights to use the book. Indeed this is done often enough in some circles, but in those cases the way one acquires the license is usually very different from the retail shopping experience, and often involves contracts signed by both parties, and may even not be contracts of adhesion, allowing negotiation of terms. In the case of software licensed in a similar way, nobody really thinks the License may not be applicable.
EULA's are slightly different and there are are the clickwrap EULAs, which may be legally different than the inside the box EULA's which in turn may be legally different than the Written on the Box EULAs. The law here is about as far from settled as is possible, and what is really needed is a supreme court decision that chooses to decide the matter for all possible cases, rather than just the specific case at hand. Unfortunately the supreme court usually chooses to not to be so sweeping, so sweeping decisions are generally a side effect of the use of specific logic in a decision that has not be fully limited to the specifics of the case at hand.
The problem is that many companies see no problem with paying RAND patent fees, and fail to see why that would make it not open. The is especially true in areas where patents are pooled, so if you have even one patent that might apply you add that to the pool, and either get a partial refund on the fees by being part of the pool, or having the fees waived entirely. (Depends on the specific patent pool).
Also what is an Open Specification? Is it one that is publicly available without fee? In that case the C programing language would not be an open standard, nor would many other ISO or IEEE standards that we all take for granted. (Admittedly some of those standards also have freely available standards that are effectively equivalent or even superior, like PDF, where the ISO standard is a subset of full PDF, or PNG where the ISO standard should be equivalent to the PNG specification).
Yes and no. As far as I know windows style guidelines don't emphasize these ypes of features very much. They are also not very visible in the bul-in applications that come with the OS, while for example the common dialogs for file oipening and closing are. If the OS's built-in applications supported saving only by dragging to a folder for example, then that would become very obvious, and other applications would be sure to support it. If the only way to print was dragging a file or content to a printer icon, or if that meathod was shown in the built-in OS video tutorials, then it would be more likely to work in most applications.
If Microsoft was to to write to makers of the textbooks and state that dragging to the printer icons was the preferred method of printing in Windows 8, and requesting that this be the meathod emphasized, then application would follow along.
OS Paradigms like these are as much a function of support by most software as support in the Windows Manager, core libraries or kernel. If most mac app developers did not make sure that their applications could run from any folder, then that paradigm of MacOS, that apps are icons that can be put wherever desired and run from there would fail to be a MacOS paradigm.
True, but only in very limited ways. I just dragged a PDF file to my printer and it worked fine. The Acrobat program opened and closed visibly, but otherwise it just worked. I tried to drag a .cxx file to the printer (.cxx files are associated with Visual Studio on my system, as it is the only IDE on my system, even though I'm more like to compile a program with gcc and idit it with emacs) and I get message telling me that the program only supports printing to my default printer, and asking me if i want to change my default printer. That is obviously nonsense.
Worst of all was trying to drag a .docx file to the printer. The net result of that was that some other document I already had open in Microsoft Word 2007 being broaught to the front. Nothing was printed, no print dialog opened, the file in question was not opened, nothing.
Draging file to programs works reasonably often, but not always, sometime the program attempts to embed the file in the document I'm working on instead. Dragging to a folder is quite hit and miss. I just tried that with a PDF, and was surpsied to see it create an rtf file with the desired content in it. I did the same with the part of a word document and it decided to add it to my desktop as an Active Desktop item. A piece of short lived technology from windows 98, that had just enough demand behind it that Microsoft apparently ported it to XP. So I try again with a different part of the document, and it resulted in a "scrap" file, which is an old and long abondoned peice of Microsoft technology created back when OLE was first really coming out, intended for exactly that soft of purpose, but quickly abandoned by virtuall all products, except Office, since somebody may reply on that functionality.
Further in Windows all of these even when they do work are alternatives to the traditional flow, not replacements for them.
"What I'd love to see happen with the Linux desktop is some serious re-thinkng of how a UI should be done."
Hear Hear! Yes, I too am a little disappointed that the "zenith" of Free Software seems to be cloning the look and feel of Windows, which is cloning the Mac, etc.
What about some real ground-breaking stuff - how about a marriage of GUI and Unix-y pipe goodness, where you could connect applications together in a GUI and have them do data flow type work - take the Unix filters approach one (or more) steps further?
What about getting RID of the file selector, and just using the normal file views + drag and drop to open and save files? Drag a file to your word processor, and it opens. Drag the tab from the word processor to a disk, and you save. Drag a section of a file, and you save that section. Drag that section to the desktop, and you save a cut buffer, and you can have as many cut buffers as you want.
Hell, why can't I just drag a file to a printer icon to print it? Why do I have to OPEN the file, then print it?
Somebody correct me If I'm wrong, but it sounds to me like you were just describing Plan 9 at the GUI layer.
I believe I remember reading that the desired UI paradigm was that save as worked by opening a window with an icon, what you dragged wherever you wanted the file to be. This was back before tabbed interfaces became common enough that the just dragging the a tab and dropping it resulting in a file made sense. There was no save dialog. equivlently one could just drag the dogument to the printer to print it, or to another application to open it without ever committing it to disk.
I cannot find a source for this now, so perhaps it was another fairly esoteric OS.
While this may be true, some micro-scale evolution strongly appears to have occurred in the past 200 or so years. Looking at old presidential portraits back in high school, I noted that quite a few of our earlier presidents had rather distinctive facial features in common, which are almost never seen anymore. Some of them were not only downright ugly by modern standards, but looked downright creepy. Now, I'll admit a few of them just may have had bad portraits, but there were too many of them for that alone to be the issue. I also find it almost impossible to believe that the differences are due to things like plastic surgery, since some of those feature's I've never seen on a real person, except when they had significant hollywood makeup applied to artificially create that feature.
2 cm is considered a reasonably significant height difference, but a shift of 1 kg in mass? Even people who have roughly "correct" mass (neither over-mass nor under-mass) can shift by 1 kg in a single day.
If every women in the country magically gained 1 kg tonight, most people could not even tell that this had happened. Yes, the extra mass might be noticed on some people, but on quite a few people the change would be almost impossible to detect without measuring. You really need shifts of around 2-3 kg before a difference could be reliably detected visually on the vast majority of "correct"-mass people. (Obviously on a morbidly obese woman, even 5 kg may be difficult to detect visually, while even minuscule changes on significantly under-mass women are likely to be noticed).
For the fellow US readers: 1 kg is approx 2.2 pounds, and 2 cm is only ~0.7 inch.
So that would be like a Microsoft hiring somebody to fix bugs after he showed he was able to find and exploit many of them by searching though one of the periodic Windows Source Code Leaks? Sounds possible, if the exploiter clearly did not have malicious intent, which these days would be much harder to show, since exploiting Window bugs is not likely to result in free internet access or the like.
Sure, but aren't finical systems using fixed point data types just about everywhere? Additonas and subtractions are the most common operations on fincial numbers as far as i know, with the next most common operating being mutliplications/divisitons within a limited range of values (that is multiplications by more than 1000 are rare, as as multiplications by less than one thousanth are also rare.) Seems fairly ideal for the use of fixed point representations. If floating point representations are used anywhere in a finacial system, I'd hope they would be BCD encoded floating point operations, as the various rounding errors encountered in the use of such a system generally match human expectation fairly closely, since they generally match the types of rounding errors found in doing the same calculations with paper and pencil.
Yes. The issue here sounds like they had a system clock counter that was an integer, that counted the number of 0.1 second clock ticks. Then they wanted to convert this to a floating point number in 24 bit IEEE format, They simply multiplied 0.1 by the integer in the register. Of course, that still sounds like too large an error top have occured from just that, but lets pretend it did.
There are several issues here. For missiles travelling at such speeds, using a system clock counter based on 0.1 second ticks sounds terribly coarse to me. Second, since 0.1 seconds are the baseline resolution of the system, the system should have been using floating point numbers where '1' corresponds to a decisecond rather than a second. Then the time counter would be exactly expressible in the floating point format.
Lastly, if the floating point format really needed to be in units of seconds, rather than deciseconds, the time counter should have been loaded in, having an exact representation, then it should be divided by 10, which has an exact representation. This is all prety basic to anybody who has even a limited understanding of floating point. If you understand the inherent precision of every operation even better than I do, even more improvements would be possible.
But to be honest, I'm not sure why floating point was used at all here. It sounds to me like fixed point may have worked just fine for most of these problems. (Of course, fixed point has its own set of rules ensuring maximal accuracy. )
True. A truely basic GPS system provides time and location information, (and velocity information too generally), but that is all. Technically for some purposes that is all that is needed. Geocaching could in theroy be done with such a device, although a more feature complete one is better.
Supporting waypoints, and rlative positioning is the next step, and any small device with some form of serial port (be it a real one, serial over USB, Serial over bluetooth, etc) can provide this level of functionality, most would have absolutely no problems providing very coarse grain maps. (Edges of states/countires showing up, etc). But for many uses much higher resolution is desired. At the very least, high resolution mapping is desired. In some cases, like the Google Earth applications, even areal photos are useful. (I strongly suspect that a phone with with GPS and Google Earth are far more useful for some off-road activities than traditional GPS units are, at least if network connectivity is available. Data about roads and speed limits, etc are just no of that much use.)
But for vehicle navigation, full mapping data with roads and connection information, and many waypoints for things like gas stations, and resaurants are almost essential. And those are fairly large. Not many devices can natively fit a full data set, and manufactures long ago realized that requiring users to download up to 3 out of ten regions at a time, or similar is just crap. One option then is streaming data over the internet.
Now Full mapping data for a country like the United States fits well on an SD card, and I suspect using an SDHC card, full mapping data for the EU+(Switzerland) could be put on a card. I know that Garmin devices in theory can support having full mapping data for the planet split between the build-in memory and the SD card, if the SD card was large enough, and the owner was willing to pay for all the maps. Garmin even sells maps on SD card (Writable SD cards, not the rarer SD-ROM cards that are possible but virtually never seen.)
So I'd say the real threat to standalone GPS's would come from Cell applications that use map data from an SD card. I'm not sure if any of the major GPS manufacture's applications for any phone model support using the same maps from the stand alone devices on SD cards, but that would be far more of a true threat to stand alone devices than Google's new android application.
These people aren't going to buy the DSi, both because unlike the DS Fat to DS Lite transition the new console isn't clearly better for their needs (the Lite's screens were much better, and it was actually pocketable), and because they resent the upgrade treadmill.
Very true. Let's look back at the Nintendo Handhelds from the beginning.
Game and watch. Simple, but they played only one game.
Gameboy. A reasonably versatile little platform. It was not as powerful as some rivals, with only mono speaker (but stereo headphone support), had only four shades of grey on the screen, and required four AA bateries.
Next up we had the Gameboy pocket. Based on the next generation of circuit components, this was much smaller than its predecessor, and provided similar battery life using only 2 AA batteries, but was otherwise similar. There was no reason to upgrade existing Gameboys unless the changes interested you. To the best of my knowledge it was not possible for a game to detect the difference between the two in any supported manner (although information may have leaked from some timing edge cases.)
The Gameboy lite was an interesting upgrade that came next, but was japan only. Once again from the game side, this was identical to the original gameboy.
The Gameboy Color was the first one different from game's perspective. This one would be a necessary upgrade to play some of the latest games, but had perfect backwards compatibility, and supported games that would run on the original with additional pallet information or even additional features on the GBC. The full feature set was available in GBC only games. In theory, a color/regular cart could have used all the GBC's features when available, but only a subset was used, specifically, double speed mode and full set of pallets was not used, as those could not be used with only simple branching to skip the GBC only parts on the original GB, so code path duplication would be needed. Also any well made GBC only game would still run on the original GB, if you could get in in the cartirdge slot, but would simply display a warning that the game was GBC only.
Nobody complained about the GBC too much, because it was a definite upgrade from the old system.
Next we got the GBA. Once again a definite upgrade so there were few complaints, although the backwards compatibility was a bit less then it could have been, with a few games having small issues, and the lack of the GBC's IR port. The shoulder buttons, larger screen, and significant processor improvements made this a much better machine than its predecessors.
We get the GBA-SP. The biggest complaints here were about some flaws in the GBA-SP itself, like no headphone port without adapter. It was completely compatible with the GBA, and the difference could not be detected in software. People generally did not complain because there was no reason to upgrade unless you wanted the light, or built-in rechargable battery. The old ones worked just fine for everything.
--------------------
Now we reach the end of the traditional upgrades where there were few to no complaints. most were either optional, being indistinguishable from software, or were significant improvements. Backwards campatibility was lacking a bit, in a few spots, but only with a really small number of games, or if
We get the DS. This is introduced as a third prong, and dropped backwards compatibility with everything but the Gameboy Advanced. The GBA games had pretty good compatibilily, but slightly worse than the GBC->GBA transition, and the lack of support for link cables was a real killer. So it should not be viewed as a GBA replacement, but a new console with the possibilty to play some old games, communicate with old games though editing the game's savefiles, or use the second port for expansions.
The DS-lite came out, to only limited complaints, most about the GBA carts and accessories sticking out. It was fully compatible with the existing DS in both directions
Just the other day I tried to compile Berkley SPICE for under Linux. That was a real pain in the ass, since it apparently not only predates Linux, but it also predates ANSI C and POSIX being wide-spread enough to depend on them. By default it assumed that void* pointers where not available, so it used char* pointers, unless a specific #define was used, in which case some but not all of the erroneous char*'s were converted to void*. It made incorrect assumptions about what header files included a function (relying on header files implicitly including other header files when they are not required to), in some cases, bypassed including header files, and just added extern function declarations. Since this was K&R C the function declarations (prototypes) did not list the arguments, but they still managed to use return types different from those specified in POSIX. And in a few cases, the arguments passed were of the wrong type because apparently they were specified differently in early UNIX.
That is not counting the places where a function returned a local array, rather than a copy of the array. (In fairness, the author did comment this asking if it should have been returning a copy instead.
Some of the function names conflicted with those used in C99, which they obviously could not have predicted, but did mean I needed to compile with "-std=c89 -posix", which took me a little while to realize. Etc.
So despite the code being targeted at a Unix, it took me several hours to compile it for Linux. This just goes to show that porting can be a real pain, and end users should not be required to compile programs themselves. Now, locally compiling programs can be a valid install strategy, as seen in Gentoo, but a ported must have checked on each targeted platform that the code compiles as-is, or provided patches if needed. It also is a pain if the system you are installing on does not have compilation tools for some reason, such as being an embedded system with limited space.
The simple fact of the matter is that most of these industires are locked into a model that made some sense back when it was started. Regional versions of products often made sense because of either local requirements (Different line voltage and frequency) different safty regulations, and the fact that not long ago it was prohibitively expensive to import something on a one off basis, and still for most items, ording from overseas can be pretty expensive, but still potentially viable for a consumer.
So in may industries we got a developer/designer, potentially a separate manufacturer, importers, distributors, etc. Creative efforts often had a separate producer too.
Content like television had a modified version of this model, where exclusive complete exploitation rights for some franchise in a limited geographical area is sold to another company. Producers often completely lack the rights to authorize sites like Hulu to show content outside the US, since they sold those rights already. Back when these sorts of deals first came out, this was because the producer would find it very difficult to negotiate broadcast agreements with channels overseas. There were just too many, with language barriers, and limited communication speeds. Under such a system both parties had something to gain. The regional rights holder could negotiate broadcast agreements with much more ease, and get profit through this. The production company would get revenue from overseas broadcasts which woiuld otherwise simply not not occur.
The model has become so entrenched, that I'm not sure that a production company could possibly keep enough rights to authorize international streaming, while still getting the shows aired overseas, since channels overseas are used to dealing with local rights holding companies when negotiating for broadcast rights, and would be reluctant to negotiate the rights directly with the producers, if they even are allowed to, by the contracts they have with the local rights holding companies. In this day and age, it is far more feasible for a producer to directly negotiate broadcast rights with overseas channels, so the benefit to them of the international rights holders have diminished greatly, but they are still around.
In the modern age of globalization and global connectivity, political borders should have little meaning when it comes to products or content, but many industries are locked into the old models, with little hope of changing in the short term. There are no few to no gentlemens agreements here, mostly just shortsightedness on the parts of many parties, and quite a few binding contracts where the the company with exploitation rights is not willing to let the contract be withdrawn. (As they now clearly have the better end of the deal, while originally the deal was fair or perhaps in the other direction). Combined with the existing system being so entrenched bypassing it is almost impossible, we get the nasty mess that we have.
Yes, distribution information is needed, or a measure that takes distribution into account is needed for the numbers to mean much.
Since we are working with a sample of the human population, if we were hopping to know the correlation in the population as a whole (which is probably more useful than the correlation in the particular sample), we would want a rho value range for some confidence interval, although admittedly getting a rho value for the particular sample in question is a necessary first step.
The social security numbers were just a way of having people choose completely arbitrary non-biased numbers as a base price to make a buy/don't buy decision against. Credit card numbers or phone numbers could have been used instead, or even assigning each person a completely random two digit number. The whole matter is that once they make a decision at some price, it appears that this is fairly likely to influence the price they would bid for it in an auction.
Since the initial price consideration is arbitrary and random, a shared previous cause (or influence) of both the initial decision price, and the bid price can be ruled out with high confidence. The bid price causing or influencing the initial price is similarly all but impossible. That leaves either the initial decision price causing or influencing the bid price, or the correlation found being a mere freak occurrence.
You are exactly correct. AIUI, as long as he is free to exercise the four freedoms, rms is happy. He sees nothing at all wrong about offering software in a dual-licensing scheme like this. I suspect he feels that in a perfect world nobody would ever choose to use the proprietary license option, but that there is no harm in offering it.
Harm may come if somebody uses the proprietary license to create another proprietary application without a similar dual-licensing system, but that would be the fault of developer of this new application, rather than being the fault of original application/library developer.
My description is a big room, with a blue or or gray ceiling; malfunctioning lighting, sprinklers, and climate control; and severe problems with the air not remaining stationary at times.
It is completely unsuitable for most endeavors.
Although to be fair, some slates come with small detachable keyboards that can be left in placed and pivoted around like on the laptop/tablet hybrids, giving you the choice of having an omnipresent keyboard at a cost of a little additional thickness, or not at your choice, by leaving the keyboard behind. I like that system. I image I would normally leave the keyboard attached, but I still see it as fundamentally different than the swivel screen "tablets".
Perfectly logical to have a central repository for everything. That way when Palm decides it does not want to support the phone anymore, or it goes out of business, the phone effectively becomes worthless, unless there is some way to bypass both the store, and the hosting by palm, and still be able to install software on the device.
At least with Apple, I can be reasonably confident that the company will remain around for a while, and that the App store will be there for many, many years in the future.
Given Palm's history I'd not be confident on either front.
I fully understand why regular images are left out. But leaving out the latex images is much more of a problem in many articles. The file size of those images, is surely only a small fraction of the total file size of all the images used in articles. The latter is obviously way too large for a small device.
But I've no idea what the cumulative size of the LaTeX images is so I have no idea how viable including them premade is.
The LaTeX images definitely can in theory be generated on demand, at the cost of adding quite a bit of complexity to the mobile Wikipedia implementation.
I agree that on a device like the iPhone/iPodTouch the correct way to handle external links is to launch the browser. On other devices, like the one in the article, the correct way would probably be to show the full url when the link is clicked, so it can be entered into a web browser on some other device.
Signing a petition does not mean that you agree with the views of the petitioner, it just means that you agree that the issue should be brought to a wider vote to decide the matter. I've known plenty of people who would sign pretty much any referendum or initiative in the states that have that process. In their view, it just airs more discussion and opportunities for democracy.
That may the biggest issue of all.
Is it completely implausible that some of the petition signers actually support gay rights, and were pretty confident (perhaps naively) that if it came to a vote, allowing same-sex civil unions would be upheld, making the matter settled?
The assumption that all signers actually supported ending same-sex civil unions is the real problem. If the website in question gave that impression, then defamation lawsuits (or perhaps even libel lawsuits) may be fully justified.
Wacom makes an oversized multitouch trachpad call the bambo touch. Priced at $69 dollars it is a little expensive, although there is a $100 version that also works as a wacom digitizer tablet, which is a pretty good deal in my opinion.
The normal touchpad controls apply, including the standard tap-and-half to drag, (although there is also a multitouch gesture for dragging, which is probably more convenient, and also works for clicking too). It includes the standard zoom and rotate multitouch gestures, as well as the swipe right and swipe left gestures for forwards and back. It also features a right click multi-touch gesture (two finger tap), and scrolling gesture, (two fingers sldining smoothly up and down, or left and right ((it is not specified, but also probably a mixutre of the two).
I'm not sure if the apple trackpad offers any additonal gestures, but if this interest you, you cnan check out the manual at http://www.wacom.eu/_bib_user/dealer/man_bampt_en.pdf (the US site still has the manual for the older versions lacking touch support), and can find more details about the product at www.wacom.com, including the ability to purchase online.
The tablet is fully compatible with Windows and Macs, although the Linux drivers have not yet been updated to support it. The Linux drivers are developed by a third party, using Wacom internal documentation provided under NDA, so it is only a matter of when, not if it will be supported.
Hope this helps.