Re:Never used this keystroke
on
Goodbye, Ctrl-S
·
· Score: 3, Interesting
The only Apple program I use is TextEdit, and that only for a scratch pad, so I'm more or less unaffected by that. That said, I can certainly see why it would be annoying... essentially, if you decide you want to save your changes in a new file, they want you to copy the most recent version (in Finder), then roll the original back the a previous version. The option-click "workaround" was added because people couldn't figure that out; not that they should have to, as "Save As..." should never have gone away in the first place. But, with autosave, it's somewhat of a hack, anyway; what does the original file end up looking like? Do you revert the original to the state it was in when it was last opened? The last autosave? Normally, it would retain its last manually-saved state, but there isn't one...
Replacing a 3-step process (Command-Shift-S; Type new filename, Hit Enter) with a 7-step process (Close file [to ensure your changes are saved, since you can no longer do this manually]; Copy file; Rename copy; Reopen the file; Click File -> Revert To -> Browse All Versions; Find the version you want to revert to; Click Restore).
Alternately, you can restore the old revision as a new file (the opposite workflow) in 5-steps (Click File -> Revert To -> Browse All Versions; Find the version you want; Option-Click Restore a Copy; Enter new filename; Click Save).
Of course, Apple's own documentation does imply that the "Save" option still exists. It is there in TextEdit, but I can't confirm this for any other Apple apps under Mavericks.
Bravo, Apple... Bravo.
Re:Never used this keystroke
on
Goodbye, Ctrl-S
·
· Score: 4, Informative
Quite possibly, he's a Mac user, so it would be Command-S. That, or someone loves their mouse a little too much and never bothered to learn keyboard shortcuts.
Of course, once he's learned to spell, you'll have no further quarrel with him, so step two should really be option two (and with a slight modification), as he really only need complete one step or the other.
They do for some things, just not for iMessage. They already have the SMS gateways set up, so it would (or should, at least) be trivial for them to begin using them in this manner for iMessage. Shit, though, even if they redirect those undelivered messages to/dev/null when they deactivate the number, that would be an improvement; the important part is deactivating the number. Oh, and of course passing that information back to users who are trying to send messages to that number via iMessage. I suppose, at that point, the messages could be redirected client-side, as well, regardless of configuration, since that configuration only applies to phone numbers registered and active on iMessage.
That wasn't my point. To be quite honest, these undeliverable messages have to be putting some measurable amount of load on the iMessage servers, on top of causing a usability problem for their users (e.g. the people who still have iPhones and are trying to send messages to their friends who no longer do), so it would be a benefit to Apple to devise a way to handle this.
Currently, it default behavior is to revert to SMS if a message goes undelivered for 5 minutes, and fall bask to SMS-only after a certain number of timeouts, until it can be confirmed that the recipient has signed back in to iMessage. This is done on the client-side and can be disabled entirely by the user, which is correct behavior on the client side, as it does allow the user to prevent the SMS fallback on their end; the problem comes when a recipient is no longer an iMessage user, regardless of reason.
A proper solution to this issue would have to be implemented on the server side. One idea that would work is to have the service disable the phone number after, say, 10 or so (just pulling a number out of my ass here, Apple would be able to determine what's appropriate based on their own data, either aggregate or per-user) messages, or a week of non-use (again, Apple would know what was appropriate based on their own data). In cases where the sender has disabled the MSM fallback on the client side, any queued failed messages could be sent via SMS from the server side when the number is disable on the recipient's account. This way, users still (eventually) get their messages and Apple can minimize SMS gateway costs by not sending messages via SMS in response to temporary issues.
And if you have an iPhone and no other Apple devices? Well, when it can no longer contact that device (or hell, assume all four of your iDevices fall off-deck while you're on a cruise), what should it do, then?
Sent from a MacBook Pro using Avatron Air Display on an iPad Air as a secondary display.
To be clear, I'm out of my depth on this, as well. By quite a bit, actually.
I'm just posting what seems logical at this point and hoping that someone will swoop in and point me in the right direction. I'm actually about to start development on a small mobile app for a client who doesn't have the budget to pay for custom libraries for each platform, so this is useful discussion at this point. There's plenty of budget going forward, for building the application incrementally; just no real immediate budget and the requirement to have it run on iOS, Android, and Windows.
I'll be honest and say I'm not sure about C/C++ on any of the mobile platforms. I know Palm started allowing native code on WebOS shortly before HP bought and killed that platform, and I'd be surprised to learn that it wasn't an option on Windows Mobile, Apple used to be very strict about all iOS apps being written in Objective C, but apparently they've relaxed quite a bit, and Google seems to actively discourage using their native C/C++ interfaces in most cases. I know BlackBerry is all Java, unless BBOS 10 changed that, so C/C++ doesn't seem a viable option if you want to target BlackBerry; but, then, Xamarin (the for-mobile release of Mono) doesn't seem to support BlackBerry, either.
I do know that Microsoft was involved with Xamarin, which actually has me wondering whether Windows Phone apps using Xamarin bundle the Xamarin libraries like they do on other platforms, or if they just use the native.Net libs. On one hand, bundling alleviates any platform differences, as far as program logic is concerned; on the other, using the native libs makes for a smaller package.
If you have the time to write your own libraries for each platform you're targeting, by all means, that's probably the best way to go, as you'll end up with the smallest footprint and the ability to optimize each platform's version of the library, as well as the library codebase as a whole, leaving out code that doesn't get used. Since you're a.Net guy, though, Xamarin might be something for you to look into if you ever need to do anything mobile.
The instance in which it would have been useful was one in which my assailant ran at me from across an empty parking lot, giving me plenty of time to draw, aim, and if necessary, fire.
The instance in which it would not was one in which my assailants, 3 of them, didn't bother to search me past my back pocket, where my wallet was, and would not have found the gun in the first place. In that instance, I'd have drawn as they fled, taking out the one armed assailant first, and kneecapping the two unarmed accomplices.
Were I armed, it would have happened once, not twice; and recovery would have been immediate.
And before you ask if I'd actually be able to pull the trigger, consider whether you really want to know the answer.
It wasn't until your last post that you mentioned that they shared a runtime, a fact which I was truly unaware of. And take all the pops you want at Java (I realize you weren't), I'm not a Java guy, either. Glad to see, at the end of this, we're actually on the same page; that also explains why you didn't read my post in the context of cross-platform development. I definitely agree re: Windows-only development and.Net, though; I was at the Win7 launch event and actually got excited about Metro (which is what they were calling the.Net version that shipped with Win7 before they decided they wanted to use that name for the Win8 interface), I just never had a use case for it. Years later, here I am still having never used.Net and with minimal interaction with Java, though one of those is going to change in the very near future; and as someone who uses Windows, Linux, and OSX side-by-side, it's not looking good for.Net.
I still stand by my assessment of.Net/Mono as a platform for mobile development, though; I think my reasoning is sound. I know you were never arguing for or against that, but now I'm curious, do you have any thoughts on that? It makes sense to me, if you're developing a cross-platform mobile application, you're likely to target the most popular platforms first, which means iOS and Android, which would mean Mono; at that point, you're developing against the capabilities of Mono and just have to make any required fixes for one platform, Windows Mobile (or Win RT), if you choose to release on that platform. Java is not an option on iOS or, as far as I'm aware, Windows Mobile, and Dalvik isn't real Java anyway; and the other available cross-platform libraries are all basically wrappers for HTML and javascript, so they're not viable for any processing-intensive tasks, or where you give a damn about performance, which really just leaves Mono. This is quite opposite the likely situation for cross-platform desktop development (and this is, I think, what got you thinking I was talking about.Net in terms of Windows-only development), where a.Net developer would likely target Windows first, then have to fix Mono quirks on the various other platforms they were targeting; and there are other, better, options available for cross-platform desktop development, but we're already in agreement on that, I think.
Yes, when you say "For the desktop market, you're likely targeting Windows first if you're going.Net" it means you're talking about Windows. I probably shouldn't have to explain basic English from your own hand to yourself, but it seems I apparently do.
Well, yes, you're 100% correct; assuming there's not other context, that is. The fact is, that was said in the context of comparing ".Net/Mono as a library for cross-platform mobile development" to ".Net/Mono as a library for cross-platform desktop development". Read it again now that you have the missing pieces (or just go back and read the whole post as a unit, instead of fixating on that one sentence -- the pieces aren't missing, you just missed them).
Look, you don't grasp the basic facts about how the.NET framework is packaged and deployed.
Of course I do. What good is the runtime without the corresponding library? Follow?
Christ, if you were doing WFW programming when you were 5 then you're at most what, 27 years old?
My bad. I was 5, you don't actually expect me to remember in that level of detail, do you? I would have been 11 when I started using a PC; I cut my teeth on an old TI and various Atari machines, my favorite being the 1040ST. Good job estimating my age based on my misquoting, though.
Thank you for the advice, I appreciate the time you took to write all of that. Thus far, you haven't shown me that I don't know anything; I never claimed to know everything about.Net (in fact, I'm so far from being a.Net guy it's not even funny), but you're trying to cram the "4.5 is 4.0" crap down my throat, then in the same breath mentioning that they're only the same runtime, but the libraries are different. I'll admit that was one piece of information I didn't actually know if you'll concede that the runtime is useless without the libraries. Then, you taught me something, and I wasn't completely off-base with both my observations and assumptions; it's a win-win.
you're likely targeting Windows first if you're going.Net, which means portability is likely an afterthought
So it means nothing that the entire thread has been about cross-platform development and I explicitly mention portability in the very sentence you're referring to. I talk about.Net in the post because, well, Mono is a cross-platform.Net implementation. You won't code in Mono, you code in.Net (e.g. C#), and I would have sounded like an idiot implying otherwise, which is what you seem to be doing right now.
This is just out and out false. 4.5 is based on 4.0, it's just an in place upgrade for it. 3.5 and 3.0 are based on the 2.0 runtime, so you generally have both runtimes, and then the subsequent API versions.
So, then, it stands to reason that 4.5 should supersede 4.0; in fact, by the same logic, 4.5 and 4.5.2 shouldn't coexist on the same system, either. Yet here I am, looking at it on two different Windows installations, one Win7 and one Win8.
Honestly, I'm just stating facts, but you seem to think you're important enough that your opinion of me can change those.
Java may be a horrid language (as I stated elsewhere in the thread, I've been lucky enough to have avoided writing anything in it thus far in my career, so no argument there), but it does work as advertized. Even their installer.
The only time I've had issues with Java, it's been with IcedTea on Linux, or the 1.6 JVM that Apple bundles with OSX. Oracle's Java, on the other hand, has never caused my any headaches. While I despise them as a company, I'm going to take whatever I can get from them without giving them a single penny and use it as long as it works better than the alternatives.
With that in mind, is there a better administration tool for mySQL than Oracle's mySQL Workbench? It has its quirks, but I've found nothing better, thus far.
it's a nice demonstration of Java having completely failed to deliver on its original goals though
And.NET picking up that torch and running with it. Java 8 will happily run applications written against the 1.8, 1.7, and 1.6 APIs, whereas you need to have.Net 4.5.0 installed alongside 4.5.2 if your application was written against 4.5.0; there is no backwards-compatibility there. Now, I don't fault Microsoft for this; trying to maintain perfect backwards compatibility is what made Windows a pile of shit in the first place, and it's gotten a lot better since they stopped.
This. I've written more software for Windows; I've sold more for Mac. Likewise, I've bought more for my Mac in the year I've owned it than in 27 years as a Windows user.
Mono. I'm talking about Mono. This whole discussion was about Mono. This should be obvious, if you've been reading the thread and not just cherry-picking comments, as the post to which I was replying mentioned "non-windows, non-mobile Linux home PC user consumer", the post before that (written by me) specifically mentions Mac, Linux (though not explicitly by name), and Mono, and the 3 posts leading up to that post all mention Mono, immediately following my post slyly pointing out that there are platforms other than Windows and that people do use them.
I think your lack of understanding of what you are currently trying to comment on is beginning to show at this point. We're not talking about Windows users being up to date, either; and your understanding, thinking that an up to date.Net installation is the end-all-be-all of being able to run any.Net application, is seriously flawed; a.Net application written against version 4.0 of the API will refuse to run if you only have version 4.5 installed, even though 4.5 is newer. Why? Because 4.5 isn't just newer, it's different. It is common to see Windwos systems with 4 or more versions of the.Net libraries installed, for this very reason; in fact, the "Turn Windows features on or off" pane in Win7 lists only.NET Framework 3.5.1, while I also have 4.0 installed, and on my Win8 instance, I have both 4.5 and 4.5.2 installed for various applications that rely on the subtle implementation differences therein.
As a recent Mac convert, who cut his teeth on WFW 3.11 at age 5 and has worked with and developed for every version of windows from then to now, I don't think my understanding of Windows is reasonably in question, here. I use all three major platforms on a daily basis, so it is important that I keep up; and so, I do.
Oh, so you're referring to the Java browser plugin. Yeah, you can have Java installed on your system without the browser plugin, or with the plugin disabled (as Firefox, Chrome, and Safari all do by default; I'm not sure if IE does, but I would assume so). the JRE is installed on a much larger number of systems than the stats you're gonna get from browser feature sniffing.
RAM is still a scarce resource on most consumer level systems, however. Two Java applications sharing a JVM will load the JVM into RAM exactly once; two Java applications each with their own JVM, on the other hand...
I've got 408.5GB free of my 1TB, but that doesn't mean jack if I need to fit more than 16GB of that into RAM.
Java. Oracle's implementation. Not Google's implementation, which you're referring to, which is called Dalvik. I apologize if you're having trouble keeping up, but I'm not sure how to make it any more clear that, when I say Java, I'm talking about Java, not Dalvik (which is what Google's incompatible implementation is called).
Right, they call it Dalvik, because it's not Java. Since it's not Java, it's probably not what I was talking about. Thanks for pointing that out, though, for those who may not have otherwise been able to follow along (or use Google)...
Or, you know, don't develop against the bleeding-edge newest version if you don't have full control over the environment. Pick a version that's a generation or two old and you're most likely not going to have problems. If your end user happens to have a newer JVM installed, it will behave appropriately based on the JDK you developed against.
I know I said, earlier, that I've thus far avoided developing in Java, but that doesn't mean I'm completely unfamiliar with how it works; I might not develop in it, but I do use it. A lot.
Slashdot Mirror
The only Apple program I use is TextEdit, and that only for a scratch pad, so I'm more or less unaffected by that. That said, I can certainly see why it would be annoying... essentially, if you decide you want to save your changes in a new file, they want you to copy the most recent version (in Finder), then roll the original back the a previous version. The option-click "workaround" was added because people couldn't figure that out; not that they should have to, as "Save As..." should never have gone away in the first place. But, with autosave, it's somewhat of a hack, anyway; what does the original file end up looking like? Do you revert the original to the state it was in when it was last opened? The last autosave? Normally, it would retain its last manually-saved state, but there isn't one...
Replacing a 3-step process (Command-Shift-S; Type new filename, Hit Enter) with a 7-step process (Close file [to ensure your changes are saved, since you can no longer do this manually]; Copy file; Rename copy; Reopen the file; Click File -> Revert To -> Browse All Versions; Find the version you want to revert to; Click Restore).
Alternately, you can restore the old revision as a new file (the opposite workflow) in 5-steps (Click File -> Revert To -> Browse All Versions; Find the version you want; Option-Click Restore a Copy; Enter new filename; Click Save).
Of course, Apple's own documentation does imply that the "Save" option still exists. It is there in TextEdit, but I can't confirm this for any other Apple apps under Mavericks.
Bravo, Apple... Bravo.
Quite possibly, he's a Mac user, so it would be Command-S. That, or someone loves their mouse a little too much and never bothered to learn keyboard shortcuts.
And likewise, many who take them do so because they're constantly flowing if they don't. Hormone deficiency, and BC pills bring the levels back up.
Of course, once he's learned to spell, you'll have no further quarrel with him, so step two should really be option two (and with a slight modification), as he really only need complete one step or the other.
goto fail;
}
goto fail;
Seems as though it still would/could have happened. Would it have been easier to catch? Likely. Still would have happened, though.
They do for some things, just not for iMessage. They already have the SMS gateways set up, so it would (or should, at least) be trivial for them to begin using them in this manner for iMessage. Shit, though, even if they redirect those undelivered messages to /dev/null when they deactivate the number, that would be an improvement; the important part is deactivating the number. Oh, and of course passing that information back to users who are trying to send messages to that number via iMessage. I suppose, at that point, the messages could be redirected client-side, as well, regardless of configuration, since that configuration only applies to phone numbers registered and active on iMessage.
That wasn't my point. To be quite honest, these undeliverable messages have to be putting some measurable amount of load on the iMessage servers, on top of causing a usability problem for their users (e.g. the people who still have iPhones and are trying to send messages to their friends who no longer do), so it would be a benefit to Apple to devise a way to handle this.
Currently, it default behavior is to revert to SMS if a message goes undelivered for 5 minutes, and fall bask to SMS-only after a certain number of timeouts, until it can be confirmed that the recipient has signed back in to iMessage. This is done on the client-side and can be disabled entirely by the user, which is correct behavior on the client side, as it does allow the user to prevent the SMS fallback on their end; the problem comes when a recipient is no longer an iMessage user, regardless of reason.
A proper solution to this issue would have to be implemented on the server side. One idea that would work is to have the service disable the phone number after, say, 10 or so (just pulling a number out of my ass here, Apple would be able to determine what's appropriate based on their own data, either aggregate or per-user) messages, or a week of non-use (again, Apple would know what was appropriate based on their own data). In cases where the sender has disabled the MSM fallback on the client side, any queued failed messages could be sent via SMS from the server side when the number is disable on the recipient's account. This way, users still (eventually) get their messages and Apple can minimize SMS gateway costs by not sending messages via SMS in response to temporary issues.
And if you have an iPhone and no other Apple devices? Well, when it can no longer contact that device (or hell, assume all four of your iDevices fall off-deck while you're on a cruise), what should it do, then?
Sent from a MacBook Pro using Avatron Air Display on an iPad Air as a secondary display.
To be clear, I'm out of my depth on this, as well. By quite a bit, actually.
I'm just posting what seems logical at this point and hoping that someone will swoop in and point me in the right direction. I'm actually about to start development on a small mobile app for a client who doesn't have the budget to pay for custom libraries for each platform, so this is useful discussion at this point. There's plenty of budget going forward, for building the application incrementally; just no real immediate budget and the requirement to have it run on iOS, Android, and Windows.
I'll be honest and say I'm not sure about C/C++ on any of the mobile platforms. I know Palm started allowing native code on WebOS shortly before HP bought and killed that platform, and I'd be surprised to learn that it wasn't an option on Windows Mobile, Apple used to be very strict about all iOS apps being written in Objective C, but apparently they've relaxed quite a bit, and Google seems to actively discourage using their native C/C++ interfaces in most cases. I know BlackBerry is all Java, unless BBOS 10 changed that, so C/C++ doesn't seem a viable option if you want to target BlackBerry; but, then, Xamarin (the for-mobile release of Mono) doesn't seem to support BlackBerry, either.
.Net libs. On one hand, bundling alleviates any platform differences, as far as program logic is concerned; on the other, using the native libs makes for a smaller package.
.Net guy, though, Xamarin might be something for you to look into if you ever need to do anything mobile.
I do know that Microsoft was involved with Xamarin, which actually has me wondering whether Windows Phone apps using Xamarin bundle the Xamarin libraries like they do on other platforms, or if they just use the native
If you have the time to write your own libraries for each platform you're targeting, by all means, that's probably the best way to go, as you'll end up with the smallest footprint and the ability to optimize each platform's version of the library, as well as the library codebase as a whole, leaving out code that doesn't get used. Since you're a
The instance in which it would have been useful was one in which my assailant ran at me from across an empty parking lot, giving me plenty of time to draw, aim, and if necessary, fire.
The instance in which it would not was one in which my assailants, 3 of them, didn't bother to search me past my back pocket, where my wallet was, and would not have found the gun in the first place. In that instance, I'd have drawn as they fled, taking out the one armed assailant first, and kneecapping the two unarmed accomplices.
Were I armed, it would have happened once, not twice; and recovery would have been immediate.
And before you ask if I'd actually be able to pull the trigger, consider whether you really want to know the answer.
It wasn't until your last post that you mentioned that they shared a runtime, a fact which I was truly unaware of. And take all the pops you want at Java (I realize you weren't), I'm not a Java guy, either. Glad to see, at the end of this, we're actually on the same page; that also explains why you didn't read my post in the context of cross-platform development. I definitely agree re: Windows-only development and .Net, though; I was at the Win7 launch event and actually got excited about Metro (which is what they were calling the .Net version that shipped with Win7 before they decided they wanted to use that name for the Win8 interface), I just never had a use case for it. Years later, here I am still having never used .Net and with minimal interaction with Java, though one of those is going to change in the very near future; and as someone who uses Windows, Linux, and OSX side-by-side, it's not looking good for .Net.
.Net/Mono as a platform for mobile development, though; I think my reasoning is sound. I know you were never arguing for or against that, but now I'm curious, do you have any thoughts on that? It makes sense to me, if you're developing a cross-platform mobile application, you're likely to target the most popular platforms first, which means iOS and Android, which would mean Mono; at that point, you're developing against the capabilities of Mono and just have to make any required fixes for one platform, Windows Mobile (or Win RT), if you choose to release on that platform. Java is not an option on iOS or, as far as I'm aware, Windows Mobile, and Dalvik isn't real Java anyway; and the other available cross-platform libraries are all basically wrappers for HTML and javascript, so they're not viable for any processing-intensive tasks, or where you give a damn about performance, which really just leaves Mono. This is quite opposite the likely situation for cross-platform desktop development (and this is, I think, what got you thinking I was talking about .Net in terms of Windows-only development), where a .Net developer would likely target Windows first, then have to fix Mono quirks on the various other platforms they were targeting; and there are other, better, options available for cross-platform desktop development, but we're already in agreement on that, I think.
I still stand by my assessment of
Wow... misspoke... In the last paragraph, I meant to say "Thus far, you haven't shown me that I don't know anything I actually claimed to know".
Yes, when you say "For the desktop market, you're likely targeting Windows first if you're going .Net" it means you're talking about Windows. I probably shouldn't have to explain basic English from your own hand to yourself, but it seems I apparently do.
Well, yes, you're 100% correct; assuming there's not other context, that is. The fact is, that was said in the context of comparing ".Net/Mono as a library for cross-platform mobile development" to ".Net/Mono as a library for cross-platform desktop development". Read it again now that you have the missing pieces (or just go back and read the whole post as a unit, instead of fixating on that one sentence -- the pieces aren't missing, you just missed them).
Look, you don't grasp the basic facts about how the .NET framework is packaged and deployed.
Of course I do. What good is the runtime without the corresponding library? Follow?
Christ, if you were doing WFW programming when you were 5 then you're at most what, 27 years old?
My bad. I was 5, you don't actually expect me to remember in that level of detail, do you? I would have been 11 when I started using a PC; I cut my teeth on an old TI and various Atari machines, my favorite being the 1040ST. Good job estimating my age based on my misquoting, though.
Thank you for the advice, I appreciate the time you took to write all of that. Thus far, you haven't shown me that I don't know anything; I never claimed to know everything about .Net (in fact, I'm so far from being a .Net guy it's not even funny), but you're trying to cram the "4.5 is 4.0" crap down my throat, then in the same breath mentioning that they're only the same runtime, but the libraries are different. I'll admit that was one piece of information I didn't actually know if you'll concede that the runtime is useless without the libraries. Then, you taught me something, and I wasn't completely off-base with both my observations and assumptions; it's a win-win.
Because you were talking about Windows.
Or, really now?
you're likely targeting Windows first if you're going .Net, which means portability is likely an afterthought
So it means nothing that the entire thread has been about cross-platform development and I explicitly mention portability in the very sentence you're referring to. I talk about .Net in the post because, well, Mono is a cross-platform .Net implementation. You won't code in Mono, you code in .Net (e.g. C#), and I would have sounded like an idiot implying otherwise, which is what you seem to be doing right now.
This is just out and out false. 4.5 is based on 4.0, it's just an in place upgrade for it. 3.5 and 3.0 are based on the 2.0 runtime, so you generally have both runtimes, and then the subsequent API versions.
So, then, it stands to reason that 4.5 should supersede 4.0; in fact, by the same logic, 4.5 and 4.5.2 shouldn't coexist on the same system, either. Yet here I am, looking at it on two different Windows installations, one Win7 and one Win8.
Honestly, I'm just stating facts, but you seem to think you're important enough that your opinion of me can change those.
Java may be a horrid language (as I stated elsewhere in the thread, I've been lucky enough to have avoided writing anything in it thus far in my career, so no argument there), but it does work as advertized. Even their installer.
The only time I've had issues with Java, it's been with IcedTea on Linux, or the 1.6 JVM that Apple bundles with OSX. Oracle's Java, on the other hand, has never caused my any headaches. While I despise them as a company, I'm going to take whatever I can get from them without giving them a single penny and use it as long as it works better than the alternatives.
With that in mind, is there a better administration tool for mySQL than Oracle's mySQL Workbench? It has its quirks, but I've found nothing better, thus far.
it's a nice demonstration of Java having completely failed to deliver on its original goals though
And .NET picking up that torch and running with it. Java 8 will happily run applications written against the 1.8, 1.7, and 1.6 APIs, whereas you need to have .Net 4.5.0 installed alongside 4.5.2 if your application was written against 4.5.0; there is no backwards-compatibility there. Now, I don't fault Microsoft for this; trying to maintain perfect backwards compatibility is what made Windows a pile of shit in the first place, and it's gotten a lot better since they stopped.
This. I've written more software for Windows; I've sold more for Mac. Likewise, I've bought more for my Mac in the year I've owned it than in 27 years as a Windows user.
Mono. I'm talking about Mono. This whole discussion was about Mono. This should be obvious, if you've been reading the thread and not just cherry-picking comments, as the post to which I was replying mentioned "non-windows, non-mobile Linux home PC user consumer", the post before that (written by me) specifically mentions Mac, Linux (though not explicitly by name), and Mono, and the 3 posts leading up to that post all mention Mono, immediately following my post slyly pointing out that there are platforms other than Windows and that people do use them.
.Net installation is the end-all-be-all of being able to run any .Net application, is seriously flawed; a .Net application written against version 4.0 of the API will refuse to run if you only have version 4.5 installed, even though 4.5 is newer. Why? Because 4.5 isn't just newer, it's different. It is common to see Windwos systems with 4 or more versions of the .Net libraries installed, for this very reason; in fact, the "Turn Windows features on or off" pane in Win7 lists only .NET Framework 3.5.1, while I also have 4.0 installed, and on my Win8 instance, I have both 4.5 and 4.5.2 installed for various applications that rely on the subtle implementation differences therein.
I think your lack of understanding of what you are currently trying to comment on is beginning to show at this point. We're not talking about Windows users being up to date, either; and your understanding, thinking that an up to date
As a recent Mac convert, who cut his teeth on WFW 3.11 at age 5 and has worked with and developed for every version of windows from then to now, I don't think my understanding of Windows is reasonably in question, here. I use all three major platforms on a daily basis, so it is important that I keep up; and so, I do.
It's flies... in the sky... doesn't that qualify as cloud-based?
Oh, so you're referring to the Java browser plugin. Yeah, you can have Java installed on your system without the browser plugin, or with the plugin disabled (as Firefox, Chrome, and Safari all do by default; I'm not sure if IE does, but I would assume so). the JRE is installed on a much larger number of systems than the stats you're gonna get from browser feature sniffing.
RAM is still a scarce resource on most consumer level systems, however. Two Java applications sharing a JVM will load the JVM into RAM exactly once; two Java applications each with their own JVM, on the other hand...
I've got 408.5GB free of my 1TB, but that doesn't mean jack if I need to fit more than 16GB of that into RAM.
Java. Oracle's implementation. Not Google's implementation, which you're referring to, which is called Dalvik. I apologize if you're having trouble keeping up, but I'm not sure how to make it any more clear that, when I say Java, I'm talking about Java, not Dalvik (which is what Google's incompatible implementation is called).
Right, they call it Dalvik, because it's not Java. Since it's not Java, it's probably not what I was talking about. Thanks for pointing that out, though, for those who may not have otherwise been able to follow along (or use Google)...
Or, you know, don't develop against the bleeding-edge newest version if you don't have full control over the environment. Pick a version that's a generation or two old and you're most likely not going to have problems. If your end user happens to have a newer JVM installed, it will behave appropriately based on the JDK you developed against.
I know I said, earlier, that I've thus far avoided developing in Java, but that doesn't mean I'm completely unfamiliar with how it works; I might not develop in it, but I do use it. A lot.