So let me get this... Not only does WP7 lock the card through standard SD mechanisms, it uses it in a RAID0 configuration with the internal memory (as pointed out by another poster) and accesses it so frequenly that virtually all cards on the market will be physically damaged. If the card is damaged or removed, not only will the card be unusable but so will be any data you had on the phone.
Microsoft has really managed to create a device less compatible with microSD cards than the iPhone, which doesn't even have a microSD slot. That's... that's quite impressive, really. The decision to make data on the internal flash dependent on the health of the SD card is pretty insane but... I mean, wow.
I wonder if Microsoft will at some point notice that their attitude of "we define the specs and the market will follow" does not neccessarily work.
Software management on Windows is horrible. Software management on OS X is quite nice. (Linux as well, for that matter.)
Yes, every program bundles their own libraries except for those provided by OS X (and Apple provides most fundamentals including traditional heavyweight X11). On the other hand, installation is a non-issue for most GUI programs. Updates are managed on a per-application basis but many applications are relying on the Sparkle library, giving them standardized upgrade behavior.
One big advantage OS X's bundle system has for users: You can use software without having to compile it yourself even as a non-administrator. This is very nice on university workstations where you might just end up needing a particular program that the university doesn't offer. On Linux you'd need to compile the program yourself. On Windows you'd be unable to do anything. On OS X you put a file (actually a directory) on your desktop.
Yeah, I can imagine that administrators are less than enthusiastic about users being able to run random stuff but if you want to forbid it I'm certain you could do so via policies.
There are advantages and disadvantages to this model. Which outweigh which depend on your situation... And obviously the model works much better when the big and/or important parts like X11 or the window toolkit are centralized. There's a difference between a program that comes with ten megabytes of redundant dependencies and one that comes with three hundred megabytes covering everything from glibc to GNOME.
All that nonwithstanding, however, I think this program will be used more to move programs from one computer to the next without having to figure out its dependencies than to fundamentally change the way Linux programs are managed. Packages work well for Linux and are a proven technology on the platform. Bundles also work well but they work well on OS X, which was designed to revolve around them. Trying to move either to the other platform will lead to acceptable but suboptimal results (as Fink, MacPorts and Portage/Mac illustrate).
They will release it as the "Kin ect" (with "ect" being an acronym for "Enhanced Cellular Technology") and add some functionality that allows you to sync it with your Xbox.
Then they'll count Kin sales for both the mobile and console peripheral markets.
In one instance, a mother with a baby in her arms is unable to easily perform simple tasks, such as checking email, on a computer.' Users of the 'Foot-Based Interface for Interacting With a Computer,' however, will be able to move their feet and step on the floor a la DDR to execute various commands, such as deleting email or scrolling down the screen.
For some reason I don't think it's quite a good idea to play DDR (or even emulate the DDR menu system) while holding a baby.
Nah. The ocean ain't better at all. I mean, have you looked at the water in the ocean? Most of it is under the surface. In terms of sea-worthiness these floating cities beat the ocean by a wide margin.
And what prevents an app from scattering its config files everywhere where the user has write permissions.
Nothing prevents it from doing that today. Nothing but convention. Does that mean the registry is a failure because programs have filesystem access and could theoretically litter all over the place? No, it just means that conventions usually work.
If the convention says "store all configuration data in %USERPROFILE%\AppData\Local\%APPNAME\" then people would do that. Some wouldn't but those people wouldn't use the registry under the current convention either.
Well, you cannot break backward compatibility or the users will not upgrade to the new version. Microsoft found that out with Vista.
No, Vista just taught them that doing something badly yields bad results. Randomly breaking backwards compatibility is usually unneccessary as more nuanced appreoaches are available.
Getting rid of an old API is as easy as deprecating it, providing a clean migration path to the replacement and dropping it one or two major releases later. Microsoft could do that with the current registry and it would work.
Just turning off the registry from one release to the next without warning the developers beforehand is a horrible idea, of course. Modifying it so it transparently accesses per-user-per-application hives, designing it so that old programs still work would give the Windows world the benefits of per-application settings while maintaining compatibility.
Or, if that's too hackish for you, offer a new per-application configuration API and the old registry in parallel but deprecate the registry and drop it in a few major releases.
Yes, people will complain that their program from 2010 doesn't work with their Windows from 2020 but the Windows from 2018 is compatible and will be supported until 2028. And if you still need that old program at that point chances are you'll need old hardware to run it anyway so you might as well stick with Windows 2018 on that box.
It's BILD. Between their obvious bias, lack of research, failure to follow commonly accepted journalistic standards and all-around lack of professionalism they're often indistinguishable from satire magazines. I mean, this is the "newspaper" that tried to tell us that DSLAMs can upsample SD content to full-quality HD using "fiber glass refiners".
If anything, BILD reporting on $ENTITY doing something wrong is an indicator that $ENTITY is innocent and in fact isn't even directly involved at all. Of course this time they were apparently lucid enough to blame an involved party, which qualifies as high quality reporting for them.
No, we're talking about mobile phone technologies. A more reasonable generation list would be this:
G1: Analog.
G2: Digital.
G3: Even more descretized than digital. Perhaps using a full byte to encode each bit.
G4: Using digital technology to run a physical simulation of a G3 telephone performing the call. The towers are also running simulations of G3 towers.
G5: Marketed as the mobile network of the future but it runs too hot and IBM can't deliver enough units.
Well, if it surpasses their 3G network they can call it 4G. And the other, faster providers could just agree that *G is a pure marketing term and go and calling their networks 5G, 6G...
That's what I think too. You're supposed to make no money from your app while paying license fees to them. Which sounds very much like "we don't want to give data access to you but it'd be bad PR if we didn't offer it at all".
Some of your ides are nice bt I do see a few problems with some.
2. Dynamic error detection. Give me a little underline when I write out a variable that hasn't been defined yet. Give a soft red background to lines of code that wouldn't compile. That sort of thing.
Of course this would mean that the IDE would be rather busy constantly inspecting your code as yout type. This would most likely make ther IDE less responsive unless you're on a beefy machine with really fast I/O.
6. Right-click to jump to anything. Right-click a variable to jump to the declaration, or goto other places it is used. Right-click a class name to bring up that class definition.
No. I happen to like the idea of a contextual menu and having the right mouse button open one is an extremely widespread convention. You could do something like alt+right click, though.
Good point. Much of localization involves rethinking some of your assumptions. For instance, OpenOffice stubbornly insists (whether AutoCorrect is on or off) that a string like "5/7" must always denote a date even though I'm in Germany, using a German locale and we never use slashes in dates over here, much less in the format M/D/Y. That's localization and no amount of not supporting the local character set will save you from it.
(I really like the argument that using ASCII saves you from having to test your system for multiple regions. It's true; if your software can't easily be ported to different regions you won't sell it abroad and thus won't have to test it...)
I am not certain that "you might at one day sell your code to a foreign company that is somehow unable to do a global search-and-replace" should limit your design. You should write code appropriate to your domain. If your domain happens to be the Norwegian tax code it seems reasonable to use proper terminology (especially since it seems unlilkely that China is going to adopt the Norwegian tax code).
Or is it "never code something that might be inconvenient to foreign coders"? That would point to C being badly designed as it uses tons of curly braces and square brackets which are rather inconvenient to type on a German QWERTZ keyboard. Ritchie really should've restrained himself.
You don't need a glyph for "=>" for instance. Anyone who knows what = and > mean individually can discern the meaning.
Of course this can lead to clashing conventions. Most programmers would agree that "a--" means to decrement the variable a. Many TeX users would agree that it means there's an en-dash behind the "a".
Unicode in control characters might make sense in very specific circumstances. I cite the program suite "Language, Proof and Logic", which is used in university logic courses. You use special, program-specific keybindings to type quantifiers not easily found on any standard keyboard. There's a learning curve but in the context of the programs it's much better to have access to domain-specfic glyphs like quantifiers than to use your imaginaton and just pretend that "\-/" is the universal quantifier. And since the set of required domain-specific characters is rather small it's not a big problem to get used to the programs.
Of course you could do like IMEs do and replace certain n-graphs with the appropriate domain-specific glyphs as the user types them. Or, alternatively, store them as n-graphs but display them as domain-specific glyphs. Anyway, I submit that in domains with well-established glyphs it might be a good idea to actually use those glyphs instead of making up kind-of-similar ASCII n-graphs and trying to establish those as a parallel standard.
This is a bit of a false dichotomy as well. An ASCII-7 text is identical to the UTF-8 encoding of the same text.
Of course this only applies to texts written entirely in standard English that don't use any unusual glyphs. Take any other language on earth or any English text using ligatures or other non-ASCII glyphs and you need to transliterate and/or use lossy conversion. ASCII is only good for a rather large subset of English texts.
Case in point: I'd comment on how you implied the universal quantifier when only the existential one applies but neither ASCII nor Slashdot's unique character set include either of them.
thing is, I have a { key and a } key, but not a [RED] key, nor a [BLUE] key. Which means either memorizing IDE-specific keyboard shortcuts (and then relearning when i have to use a new tool), or lots of clicky-clicky with the mouse, which takes longer and does more damage over time.
Which only makes sense since colorForth looks like it was explicitly designed to draw aggro from developers.
Slashdot Mirror
I'm not certain whether product information qualifies as protected speech.
So let me get this... Not only does WP7 lock the card through standard SD mechanisms, it uses it in a RAID0 configuration with the internal memory (as pointed out by another poster) and accesses it so frequenly that virtually all cards on the market will be physically damaged. If the card is damaged or removed, not only will the card be unusable but so will be any data you had on the phone.
Microsoft has really managed to create a device less compatible with microSD cards than the iPhone, which doesn't even have a microSD slot. That's... that's quite impressive, really. The decision to make data on the internal flash dependent on the health of the SD card is pretty insane but... I mean, wow.
I wonder if Microsoft will at some point notice that their attitude of "we define the specs and the market will follow" does not neccessarily work.
Software management on Windows is horrible. Software management on OS X is quite nice. (Linux as well, for that matter.)
Yes, every program bundles their own libraries except for those provided by OS X (and Apple provides most fundamentals including traditional heavyweight X11). On the other hand, installation is a non-issue for most GUI programs. Updates are managed on a per-application basis but many applications are relying on the Sparkle library, giving them standardized upgrade behavior.
One big advantage OS X's bundle system has for users: You can use software without having to compile it yourself even as a non-administrator. This is very nice on university workstations where you might just end up needing a particular program that the university doesn't offer. On Linux you'd need to compile the program yourself. On Windows you'd be unable to do anything. On OS X you put a file (actually a directory) on your desktop.
Yeah, I can imagine that administrators are less than enthusiastic about users being able to run random stuff but if you want to forbid it I'm certain you could do so via policies.
There are advantages and disadvantages to this model. Which outweigh which depend on your situation... And obviously the model works much better when the big and/or important parts like X11 or the window toolkit are centralized. There's a difference between a program that comes with ten megabytes of redundant dependencies and one that comes with three hundred megabytes covering everything from glibc to GNOME.
All that nonwithstanding, however, I think this program will be used more to move programs from one computer to the next without having to figure out its dependencies than to fundamentally change the way Linux programs are managed. Packages work well for Linux and are a proven technology on the platform. Bundles also work well but they work well on OS X, which was designed to revolve around them. Trying to move either to the other platform will lead to acceptable but suboptimal results (as Fink, MacPorts and Portage/Mac illustrate).
You failed both to capitalize "Pies" and to tell us what the tenth planet is. I hope it's made of pie.
They will release it as the "Kin ect" (with "ect" being an acronym for "Enhanced Cellular Technology") and add some functionality that allows you to sync it with your Xbox.
Then they'll count Kin sales for both the mobile and console peripheral markets.
Unfortunately I never got around to actually getting Garry's Mod. I hope someone else can help you.
If you want to see how this would work in practice I recommend that you do an image search for "garry's mod".
In one instance, a mother with a baby in her arms is unable to easily perform simple tasks, such as checking email, on a computer.' Users of the 'Foot-Based Interface for Interacting With a Computer,' however, will be able to move their feet and step on the floor a la DDR to execute various commands, such as deleting email or scrolling down the screen.
For some reason I don't think it's quite a good idea to play DDR (or even emulate the DDR menu system) while holding a baby.
Just as important would be the ability to quickly relocate to the San Francisco Bay.
Didn't he manage to actually sink the set used in Waterworld? I wouldn't let him anywhere near one of those cities.
Nah. The ocean ain't better at all. I mean, have you looked at the water in the ocean? Most of it is under the surface. In terms of sea-worthiness these floating cities beat the ocean by a wide margin.
Chinese officials have confirmed that American ICBM targeting systems are on par with Chinese ones - both point at the USA.
And what prevents an app from scattering its config files everywhere where the user has write permissions.
Nothing prevents it from doing that today. Nothing but convention. Does that mean the registry is a failure because programs have filesystem access and could theoretically litter all over the place? No, it just means that conventions usually work.
If the convention says "store all configuration data in %USERPROFILE%\AppData\Local\%APPNAME\" then people would do that. Some wouldn't but those people wouldn't use the registry under the current convention either.
Well, you cannot break backward compatibility or the users will not upgrade to the new version. Microsoft found that out with Vista.
No, Vista just taught them that doing something badly yields bad results. Randomly breaking backwards compatibility is usually unneccessary as more nuanced appreoaches are available.
Getting rid of an old API is as easy as deprecating it, providing a clean migration path to the replacement and dropping it one or two major releases later. Microsoft could do that with the current registry and it would work.
Just turning off the registry from one release to the next without warning the developers beforehand is a horrible idea, of course. Modifying it so it transparently accesses per-user-per-application hives, designing it so that old programs still work would give the Windows world the benefits of per-application settings while maintaining compatibility.
Or, if that's too hackish for you, offer a new per-application configuration API and the old registry in parallel but deprecate the registry and drop it in a few major releases.
Yes, people will complain that their program from 2010 doesn't work with their Windows from 2020 but the Windows from 2018 is compatible and will be supported until 2028. And if you still need that old program at that point chances are you'll need old hardware to run it anyway so you might as well stick with Windows 2018 on that box.
It's BILD. Between their obvious bias, lack of research, failure to follow commonly accepted journalistic standards and all-around lack of professionalism they're often indistinguishable from satire magazines. I mean, this is the "newspaper" that tried to tell us that DSLAMs can upsample SD content to full-quality HD using "fiber glass refiners".
If anything, BILD reporting on $ENTITY doing something wrong is an indicator that $ENTITY is innocent and in fact isn't even directly involved at all. Of course this time they were apparently lucid enough to blame an involved party, which qualifies as high quality reporting for them.
Only if you assume that history is global. It isn't, however, it's merely shared between actors who can freely exchange information.
History is not about what actually happened, it's about what we think had happened.
No, we're talking about mobile phone technologies. A more reasonable generation list would be this:
G1: Analog.
G2: Digital.
G3: Even more descretized than digital. Perhaps using a full byte to encode each bit.
G4: Using digital technology to run a physical simulation of a G3 telephone performing the call. The towers are also running simulations of G3 towers.
G5: Marketed as the mobile network of the future but it runs too hot and IBM can't deliver enough units.
Well, if it surpasses their 3G network they can call it 4G. And the other, faster providers could just agree that *G is a pure marketing term and go and calling their networks 5G, 6G...
Console users call it "gay".
That's what I think too. You're supposed to make no money from your app while paying license fees to them. Which sounds very much like "we don't want to give data access to you but it'd be bad PR if we didn't offer it at all".
2. Dynamic error detection. Give me a little underline when I write out a variable that hasn't been defined yet. Give a soft red background to lines of code that wouldn't compile. That sort of thing.
Of course this would mean that the IDE would be rather busy constantly inspecting your code as yout type. This would most likely make ther IDE less responsive unless you're on a beefy machine with really fast I/O.
6. Right-click to jump to anything. Right-click a variable to jump to the declaration, or goto other places it is used. Right-click a class name to bring up that class definition.
No. I happen to like the idea of a contextual menu and having the right mouse button open one is an extremely widespread convention. You could do something like alt+right click, though.
Good point. Much of localization involves rethinking some of your assumptions. For instance, OpenOffice stubbornly insists (whether AutoCorrect is on or off) that a string like "5/7" must always denote a date even though I'm in Germany, using a German locale and we never use slashes in dates over here, much less in the format M/D/Y. That's localization and no amount of not supporting the local character set will save you from it.
(I really like the argument that using ASCII saves you from having to test your system for multiple regions. It's true; if your software can't easily be ported to different regions you won't sell it abroad and thus won't have to test it...)
I am not certain that "you might at one day sell your code to a foreign company that is somehow unable to do a global search-and-replace" should limit your design. You should write code appropriate to your domain. If your domain happens to be the Norwegian tax code it seems reasonable to use proper terminology (especially since it seems unlilkely that China is going to adopt the Norwegian tax code).
Or is it "never code something that might be inconvenient to foreign coders"? That would point to C being badly designed as it uses tons of curly braces and square brackets which are rather inconvenient to type on a German QWERTZ keyboard. Ritchie really should've restrained himself.
You don't need a glyph for "=>" for instance. Anyone who knows what = and > mean individually can discern the meaning.
Of course this can lead to clashing conventions. Most programmers would agree that "a--" means to decrement the variable a. Many TeX users would agree that it means there's an en-dash behind the "a".
Unicode in control characters might make sense in very specific circumstances. I cite the program suite "Language, Proof and Logic", which is used in university logic courses. You use special, program-specific keybindings to type quantifiers not easily found on any standard keyboard. There's a learning curve but in the context of the programs it's much better to have access to domain-specfic glyphs like quantifiers than to use your imaginaton and just pretend that "\-/" is the universal quantifier. And since the set of required domain-specific characters is rather small it's not a big problem to get used to the programs.
Of course you could do like IMEs do and replace certain n-graphs with the appropriate domain-specific glyphs as the user types them. Or, alternatively, store them as n-graphs but display them as domain-specific glyphs. Anyway, I submit that in domains with well-established glyphs it might be a good idea to actually use those glyphs instead of making up kind-of-similar ASCII n-graphs and trying to establish those as a parallel standard.
This is a bit of a false dichotomy as well. An ASCII-7 text is identical to the UTF-8 encoding of the same text.
Of course this only applies to texts written entirely in standard English that don't use any unusual glyphs. Take any other language on earth or any English text using ligatures or other non-ASCII glyphs and you need to transliterate and/or use lossy conversion. ASCII is only good for a rather large subset of English texts.
Case in point: I'd comment on how you implied the universal quantifier when only the existential one applies but neither ASCII nor Slashdot's unique character set include either of them.
thing is, I have a { key and a } key, but not a [RED] key, nor a [BLUE] key. Which means either memorizing IDE-specific keyboard shortcuts (and then relearning when i have to use a new tool), or lots of clicky-clicky with the mouse, which takes longer and does more damage over time.
Which only makes sense since colorForth looks like it was explicitly designed to draw aggro from developers.