Of course they can control their economic destiny. They could impose massive spending cuts, refuse to pay pensions, take big wage cuts and so on, and trigger the recession that way. But they'd rather not (no surprise)
Bitcoin is not actually deflationary. Its supply grows constantly until it eventually stabilises. The fact that Bitcoin prices have fallen a lot is more because lots of new people have discovered the project and decided they want some, but that effect will eventually peter out as Bitcoin becomes boring and everyone finalises their opinions of it.
Greece doesn't need fiat currency. What Greece needs is hard money – like the Euro (which is hard-ish, though not as hard as Bitcoin). This is because the Greek government is notoriously corrupt and the fact that they couldn't just print the pensions of their civil servants was one of the few things creating pressure to reform, and preventing outright pillaging of the savings of Greeks who do actually work in the private sector. Seeing Greece as one monolithic entity isn't right: there are different factions, not all of whom want the government to suddenly be able to spend whatever it wants. Hence the Greek people apparently voting for both keeping the Euro and not enacting any spending cutbacks, a contradictory position.
Ultimately Greece is going to get a lot poorer, no matter what. In many ways it's practically a third world country, one that was simply kept afloat by huge injections of foreign cash. But it never really stopped being third world in the way that it was run.
Bitcoin could, theoretically, benefit some Greek people now in the heat of the crisis because the Greek government wouldn't be able to impose capital controls on it. Thus preventing the outright theft of whatever little cash Greek's have left in the bank (sorry, I mean, solidarity tax/haircut/pick euphemism of choice). It is no magical cure for Greece's problems but it could tip the balance away from a government that discovered it was paying salaries and pensions for entirely non-existent departments, and towards people who are just trying to make a living.
Lots of things can be considered an API. For instance, who owns the copyright on OpenGL? Does anyone even know? What about HTTP? After all, a protocol is basically an API that runs over wires instead of call stacks. And HTTP/2.0 is a derivative work of SPDY which is
Following this US ruling all sorts of people and companies are now finding that they own IP they never even knew they had. This is already making lawyers the world over start licking their lips. It's going to be a shitstorm.
Ah, I see. I think I have erased from my memory the time when my daily commute was measured in hours -- I could only stand it for a few years early in my career and then gave up and moved to a job closer to home. I do sympathise, though.
Of course they will (and do). They want their customers to have a great experience so they don't go to the competition. Hence the ability to review drivers, hence the automated calculation of the trip cost and so on.
Only the first few times. Then it's just annoying.
It's systematically ignoring laws and regulations while going "wah wah, we're teh underdogs".
Uber is not unregulated and they do not stand in opposition to regulations in general, contrary to what many seem to believe.
What we're witnessing here is not State Vs Anarchy Round One. What we're witnessing is quite simply State Regulation vs Corporate Regulation. The existential question Uber faces is, can they convince society and government (not the same thing) that they're better at regulating taxi drivers via their technology than local taxi commissions are via paperwork? Even if Uber triumphs, this will not mean widespread usage of unregulated taxis, it just means that taxi drivers will live in fear of getting low star ratings instead of having their local medallion revoked.
Getting drunk and running amok is something you do when not home--at home you might exercise some moderation, or there'd be people who'd call you out on it whose authority you'd feel obligated to respect
I hate to say it, given that I'm British, but unfortunately the problem of a subset of Brits getting completely wasted and engaging in shitty, boorish behaviour isn't something restricted to holiday times. For some reason the UK just has a far more serious problem with drinking than other cultures and it happens at home as well. I normally don't go to the sort of European resort towns that the hooligan set like to frequent but on the occasions that I have done, it's always embarrassing as fuck to be a young male British tourist because you can sense the suspicion locals have that you might be about to do something stupid. The worst was when I visited Bratislava. Lovely city (well, town, by UK standards). The pub in the city centre had the phone number of the British embassy on the beer mats, for people to call in an emergency. The men's toilets had a poster warning Brits specifically not to hit on the local girls. When I was there, a group of Brits came in with some unbelievably grotesque, obese men being led by some extremely hot local girl. Very obviously a stag do. As one of the fattest guys walked past the table where me and my friend were sitting he said (very loudly) "I want to see some TITS".
I pretended to be Canadian. Luckily I don't have a strong British accent at all and I was travelling with an American, so it was somewhat plausible.
I think you're completely right that this behaviour is partly learned and transmitted, like some sort of mind virus. For some reason Brits seem far more likely than other people to feel they can't have fun or be socially relaxed until they've got drunk, and will happily admit it. It's not seen as something shameful, people just blurt it out, like saying it somehow makes them one of the group. Combine it with a culture that practically celebrates "laddishness" as being fundamental to being a man, and you've got a recipe for trouble.
For a server it's different because each service has its own location for config and data, but if your job is to setup and manage the server then you should know what its running and where those services keep their data.
That's a great theory, but in the real world numerous people rely on servers that don't have a dedicated admin, so these things do matter and "You should know everything about everything" isn't a terribly useful philosophy (leaving aside the often incomplete nature of documentation in FOSS world, which can make it hard for even a competent and generally knowledgeable admin to actually know everything they need to here).
In this context, I'd take backing up user data and reinstalling Windows and its applications over backing up user data and reinstalling Linux and its application any day of the week.
So they should never run scans because every time your computer is on you are using it?
The kind of entire system scan that slows everything down for an extended period? No, probably not. Those scans are mostly worthless from a security point of view, and have a high impact on the overall efficiency of the system.
They should never patch and just let well known vulnerabilities run amok because you don't want to be inconvenienced, either by having to leave your machine on or wait while patching happens?
Of course not. But we aren't talking about rolling out the approved updates across the organisation after Patch Tuesday or whatever we're calling it this month. We're talking about regular scanning that routinely interferes with normal use of the system.
You left them no choice by giving them no time that wasn't work time.
There are plenty of other choices, starting with having sensible security practices that don't routinely undermine systems at all, and closely followed by having a standard procedure for applying security updates in a timely fashion that allows for things like people being out of contact for extended periods and provides for notifying them of any urgent threats while they are away and then getting them fully caught up when they return.
If the process of installing updates and perhaps a reboot on a Windows box is itself taking so long that it can't be done in the background while someone is making a coffee, again you probably have bigger problems to deal with and need to consider whether the spec of your systems is good enough what what you need to do with them. But in the real world, this is almost never a problem in practice if you have a remotely sensible set-up.
That's how you see it, not how IT, nor Management, nor lots of other orgs see it.
Frankly, I think it's how responsible IT and smart Management see it as well, and I don't know what "other orgs" you mean so there's little to say there.
IT is a support function. The purpose of support functions is to support the primary functions of your business. Any time your support functions start undermining the primary functions, that should be robustly justified, or the people who want to do it should be told "no". It's really as simple as that.
As for your example scenario, that's the kind of foolishness that costs real businesses money all over the place. I bought some quite expensive household goods a little while ago, and as it happened we were just finishing up the paperwork at 8pm as the showroom "closed". The sales guy was incredibly apologetic about how he couldn't print the last form we had to sign -- which was the important one that guaranteed us the goods and them the sale -- because their central management system went off-line for something-or-other and despite it being 8:01pm and him having a high value customer waiting to complete a sale, he couldn't.
As a direct result of the poor policy imposed on the local store by some genius in central IT, they were at risk of losing one of only a few final sales they would have made that entire day; in fact, if it had been one day later, they would have done, because we would have been on holiday and so not able to return the following day to finish everything off as we actually did. That is what management technically refers to as a "total screw up".
Actually, their IT systems generally were a disaster. On our first visit, they had multiple people looking around at one point. However, it took so long to put a provisional order into their prehistoric computer system to get a proper quote (seriously, like an hour to do what should have been maybe 5 minutes) that people were literally walking out after waiting half an hour to see the sales guy who was tied up with the other customer.
I can easily imagine based on just those experiences that dumping seven figures into building a modern IT system that could handle customer orders properly would increase their revenues by 25-50% indefinitely. It obviously wasn't a new or unique problem, as the sales guys on both occasions seemed both genuinely apologetic but also had a well-rehearsed patter for how it happens sometimes but no-one ever fixes it.
To be fair, if you're dealing with the level of malware that can cover its tracks against that kind of investigation, and if that malware is already on your system but wasn't picked up on a previous scan, the game is already over anyway and you're well into complete reinstall and restore from back-ups territory. These days, with threats that can hide in other areas of the hardware/firmware to survive the wipe and reinstall process, I'd be wary of trusting even that in any highly security-sensitive environment.
I'm freelance these days, so I'm afraid I can't help. Sorry.
One of my regular clients operates in this field, and seeing things done in a reasonable way reminds me of why I used to get so irritated when I did work as part of a large, bureaucratic institution. It's not magic. It's just being aware of modern tools and practices, and being willing to make the effort (and yes, sometimes, being willing to spend the money) to set up something that provides a useful degree of security but without making things so secure that you forget why you're there in the first place.
Given the potential costs of getting security wrong, I don't really understand why any organisation large enough to be facing these issues regularly wouldn't hire people who know what they're doing and provide a reasonable budget for them to deploy proper tools. I can only assume it's the usual suspects, probably some combination of ignorance and corporate politics.
Full disclosure: Obviously I make money from working for that client and they make money in part from selling some of those tools, so I'm kinda sorta shilling here. But not really, because really, the cost of hiring smart people and giving them proper equipment vs. the cost of say a major regulatory investigation or having your whole sales team at the pub all day because they can't work... not exactly close.
They shouldn't be doing their work at home - which is what the GP said.
Oh, OK then. It's not like full- or even part-time telecommuting is one of the most advantageous perks offered by many modern workplaces in terms of productivity or staff morale, so I don't suppose the business will suffer too much. Should I also recall our entire sales force and tell them they can't work on customer sites any more?
In other news, please be aware that due to a change in company IT policy, next time you get paged at 4am because of a network alert, remote access will not be permitted for security reasons. Instead, you will be required to get up, spend 20 minutes driving to the office, log in from a properly authorised and physically connected terminal, type the same one CLI command you do every time that alert goes off to confirm that it's still just the sensor that is on the blink, type the same second CLI command you do every time to shut off the alarm, spend 20 minutes driving home again, and then go back to bed. Sleep tight.
The only part I've found complex is finding out where and how various apps actually store their data, particularly when I don't really have much interest in the app.
In a sense, yes, the most important problem is that simple, but as you then demonstrated with things like the database example, "simple" and simple aren't always the same thing.
The other point I was to make is that your example presupposes that all of the packages you need are installed using your distro's package manager. In my experience that is rarely the case, and while there are tools like checkinstall that can help, the lack of any enforced installation conventions or protections against unexpected interactions in mainstream Linux distros means you are always vulnerable to certain nasty problems. Anyone's make install can probably nuke the output from anyone else's. Someone running a make uninstall that removes something that some other project assumed would be present can break the other project. Even if you stick to distro-only packages, there is not always a guarantee of backward compatibility when moving to a new version of the distro.
To me, the fundamental problem here is that for the most part I want an OS foundation that is stable and robust, and other than security fixes I probably never want it to change for the lifetime of the system. On the other hand, I want to be able to install drivers for new hardware or protocols and of course new application software on top of that OS, and I want them to have a stable platform to run against and to be as independent as possible so swapping out one part of the system doesn't undermine any other parts. The current Linux ecosystem with its distro model does not promote that kind of separation and safety, unfortunately.
"Money is the root of all money." -- the moving finger
