Because software is never finished. There's always an optimisation or a bug to fix or a feature which falls in line with the ethos of the project.
No updates == no interest from the developers and that's a bad place to be in. I'd rather use software which is actively maintained (and has some issues) that something which is robust but stagnant.
Change is the only constant.
You seem to think that a microSD slot is an unambiguously bad feature. You seem to have a list of downsides which are quite flimsy:
1) I replaced the sim slot card on my old S1 the other day (by myself, because it's actually not that difficult to do and cheap to do as well) because it had been abused and broken -- no longer reading a sim. The SAME BOARD hosted the microSD slot. It's not really a bulk issue then, is it? It's a tiny 0.5x(square dimensions of sd card) mm cubed "bulk".
2) It was on the same board. I bet it must have added around 0.5c cost.
3) The sd card slot didn't die -- the sim card slot did. Reliability of the sim slot seems to be more pertinent.
4) No-one is going to try to wedge battery in there. Not at the space it takes. Not in the place it's at. A good place to put more battery would be where that stupid fingerprint scanner is or where the NFC chip is since contactless payment is a giant fail and I've yet to see a truly innovative use for NFC. I certainly don't miss it when I swap out my S3 battery for a higher-capacity one which has dropped the NFC chip. But that is my preference, of course.
5) Depends on the model -- all of the Samsung phones I've seen (s1,s2,s3,s4, note2) have the sd card slot behind the back cover, Pretty sure the HTCs I've had contact with were the same, but I could be wrong as I didn't deal with them that long. Indeed, I don't know offhand of any modern phones which have the slot exposed like they used to, though I'm sure some exist. The point is, they don't have to.
6) The majority of Apple's devices are "third party hardware". Again, issues with sim card slot, not sd card slot. That same phone had an issue with the main board earlier on (replaced under warrantee) -- but never with the sd card slot. Odd hey?
7) True, consumers tend to choose the cheapest. Though most who are savvy enough to buy a card, shop around for one which says "fast". Or they ask a friend, like they did when they were buying other technical stuff.
8) How so? If you have a *nix-style filesystem (as do Androids and I'm pretty sure so do iPhones), then the card is mounted in somewhere into another folder. Meaning that if nothing is mounted, the folder is just a folder on the original filesystem. How is that any more complicated than any other folder on the filesystem? And if it's mounted, the fact that it is is transparent to anything casually observing the fs.
9) Preference is a fair point, but not a downside. If you prefer smaller storage and wireless sync, go ahead. Unless you're in a really first-world area though, storage of larger files becomes an issue you have to face as you can't just stream everything all the time. So it's valid to have a preference for more storage and, beyond that, the ability to expand that storage as requirements are raised, in accordance with available finances.
10) Only in the same way that USB drives, SSDs, DVDs... indeed *all* storage media are "modern day floppy disks". In the way that they are all means for storing data with variable amounts of portability. I think we do need storage media for our data, but I could be way out on a limb here. Behind the cloud is some kind of storage. Also it's quite rare to find people popping their sd cards in and out of their devices on a regular basis, so the "floppy" analogy is a bit flawed on that point and immediate access to the card is also not a priority.
I'm particularly amused that you instruct the prior poster to "stop trying to tell everyone that they are stupid because they don't care to do things just like you would" after having basically done just that. Some people want storage. Some people prefer wireless sync. It's all about preference, but you've simultaneously told another poster that their preference is stupid and that they shouldn't tell anyone else that same message.
On one point we can agree though: that poster should probably get out of the Apple camp and find a device where the makers are more interested in the needs of the user than in serving their own agendas and trying to crowd the world's landfills with discarded, fully-functioning electronic waste after collaring their obedient sheep into buying the next iteration of the same thing they did last year, only this time with most of the features they shot down in competitor products two years before after realising that their blind followers were starting to wake up and smell the coffee.
And I'm not trying to spew vitriol about Windows or services in that platform, though I'm sure you might expect that here and I might even have appeared to be doing just that (: I was just answering your question (:
I've come to understand that all tools have their rough edges. I make my living from writing software for the Windows stack and most likely will continue to do so for many years to come.
The biggest issue I have with the Windows service model is that certain services are run in the same shared process, which means that if you want to take one down, they all come tumbling down.
Secondary to that is the flakiness of the install/uninstall process -- I've found it far too easy to get the services subsystem into a dodgy state where a service is scheduled for deletion, but not actually deleted until you restart, even though it's no longer running or in use. Which means that you can't re-install a newer version of the service until you reboot because your new version shares the same name.
Tertiary to that is the fun and games that you have to endure to be able to run an application as a service but also run it once-off for debugging / development. Hence the birth of projects like this: http://www.nuget.org/packages/... (full disclosure: I wrote it and (a) I'm sure it's not a unique solution and (b) there are probably better ways of doing it but (c) I found I needed to do this far too often). Much of this hinges around how messages (start/stop/pause/resume etc) are sent to the service -- and these are also (IMO) far less elegant than *nix signals. It's also this architecture which makes a flaky service gain the ability to cause havoc with your system by not responding to requests properly, etc.
In addition, programming a service for install / uninstall is a mission in and of itself -- even the "standardised"
All of that doesn't mean that I could have done better or that it's absolute shit. It's just that it takes time to figure this stuff out -- many burned fingers before you start getting it right. And I still get the feeling (oodles of services later) that I'm missing something. Because I probably am.
I sincerely hope that systemd doesn't foist this same mess on us. I haven't investigated it enough to know much about it, but the facts that I have read (primarily who the dev team are and my experience with their prior fuckups and most especially how they like to shift blame after royally fisting someone else but also how they don't give two shits about user problems or reinventing stuff that didn't need reinventing) don't give me that warm fuzzy feeling.
PulseAudio is a great example: pretends (poorly) to be ALSA and then the devs blame userland software when audio gets choppy (even when audio wasn't choppy on ALSA). It also poorly implements features like simultaneous output to multiple physical devices and devs don't take bug reports on that shit -- I tried and was shut down for using a feature I apparently wasn't supposed to be using (ie, simultaneous output). They'd rather leave broken shit in place than fix or remove it.
I'll be honest that I don't have a broad range of experience with libraries. I've used a couple of html-to-pdf implementations and PDFSharp. The licensing for PDFSharp is very permissive, support can be paid for if required and the library is quite fast. As an aside, it has a cousin, MigraDoc, which produces abstract documents which you can finalise to Office formats, if you need that too.
IMO, there is no perfect tool, but PDFSharp has served me well.
Has this got to do with the article? Or the OP?
Indeed, what the actual fuck are you smoking? And where can I get it?
I have an SBLive sound card. Loved it for years. Defended it and all of its virtues (hardware mixing! oh, emm, gee!). Then I had to upgrade my motherboard and found that PCI is "old tech", so that card hasn't been used since then. I'm not enough of an audiophile to care (yes, it *was* better than the onboard Realtek stuff I have now) to buy a card which costs about as much as my graphics card (which provides a lot more bang for the buck) just so that I can throw it away when AMR is not the new hot shit any more.
I'd be more inclined for something USB but my experiences there have been less than stellar and posters higher up can back me up -- a lot of USB sound solutions out there are crappy-poop.
'nuff said.
How about we let the smart people tinker on their space toys until us dumb-uns can benefit?
Indeed. I think that the moment we can stop acting like a bunch of "you're wrong, I'm right" douches and just work together, we can overcome this bottleneck. Unfortunately, other commenters are about to prove how we can't by telling you how wrong [X] is and how right their version of [X] is ):
Yes, dealerships can rip you off for services. That being said, you should damn well replace oil (engine most often, gearbox at least 3 times in the time you had it), brake fluid and spark plugs, at least every 20000 km. Engine fluids are not built to last: they break down and become inefficient, costing you money at the pump, increasing your emissions, wearing your engine. If you have an air-conditioner, you also need to fill the gases there at some point -- they tend to make their way outward.
You'd probably find that your car would easily double or possibly even triple that distance if it were looked after. Cars which last longer put a lower burden on our planet as they lighten the demand for new cars, obviously.
The best bit is that oil, oil filter, brake fluid and spark-plug changes are trivial and can be done by absolutely any able-bodied person with the 10 minutes it takes to learn how.
I bet you're never more than an 10 minutes away from a power outlet but you'd also never consider owning a phone with a four hour battery life. Bear in mind that some people simply don't want to have to juice up so often, much like you wouldn't want to for your phone.
To stop confusing the terms "hacker" and "cracker". There's nothing wrong with viewing the world as malleable and acting on that, towards the premise of betterment. Engaging in a course of destruction, theft and maliciousness, however, should be vilified.
And it's one of the reasons I left. It was all part of the erosion of the "cool place to work" ethos that was there when I joined them.
If you can, vote with your feet. I totally appreciate that not everyone can. But if you can, do. And make sure that your employer knows about it. Also, it helps to inform the unaware masses if you know about it -- most of the people at my old work didn't know, and that, in and of itself, is possibly worse than the actual act.
Put your XP stuff in a VirtualBox VM. Snapshot it so you have a safe place to roll back to when it breaks (because it will) and run it on a newer OS. Win8 if you like, or some variant of Linux. The point is that XP is (like any piece of software) imperfect and bound to have security issues in the future. If you're the kind of user who doesn't go online and your world never changes, then you have no incentive to upgrade anyway. This message is aimed at people who would have some advantage in having a harder system and/or access to newer software.
Really, the only thing needed for this is a tool which guides the novice user through:
1) resizing their main drive so that there's enough space (or stop if there's no space and inform the user; disks aren't that expensive these days) to
2) dump the drive to a VB disk image, in a partition in the remaining space
3) install whatever upgrade path you've asked for (so the tool needs a "resume" mode so you can launch it again from wherever you left off)
4) set up the VB VM for use.
Ok, it's non-trivial, but the process *is* trivial for a technical user. If you're one of those, or prepared to support a family member, put your pride aside and help them to upgrade to the platform of their choice (whatever that is) with a VB VM to hold their old environment.
Stop whining about it -- decide if upgrading to anything else is actually worth it and then just do the above. Time changes everything. Life moves on. It's time you do too -- or just accept where you are and shaddup.
When you have an idea (and this applies especially to software, where it's easy to run this course), a good idea is to run an experiment -- see if your idea actually holds water.
100 million kudos points, however, to the person who recognises the experiment for what is is (an experiment) and has the kahunas to recoginise failure and roll back.
Personally, I don't like global menus, But if they had worked for most users, then that alone would have given them value -- and I'm free to not accept and work around them. I, for one, applaud the ability of Ubuntu and Shuttleworth to run an experiment, recognise failure and go back to what is known to work. It shows respect for the user.
With your bare hands?!?
