Posts by ranger 17 publicly visible posts • joined 11 Feb 2011
Exactly this. VMWare have pulled patches (https://kb.vmware.com/s/article/52345 ), as have Lenovo (https://support.lenovo.com/gb/en/solutions/len-18282 ), due to the bug in Intel's microcode fix. I'm not sure why the article suggests this is anything else.
Whilst I'm not going to defend the uplift of versions, the primary cause of the version uplifts isn't because of new core language features or syntax changes: the last big change there was v4 (I think).
But it's more that Powershell is really bash + binutils + netutils+{some other utils}. i.e., the cmdlets shipped tends to morph much more than the underlying language.
Yes, there's an argument for splitting powershell into what's really core (i.e., the PS engine) and the cmdlets, and updating them separately. A case in point is some of the new networking cmdlets - there's no real reason these couldn't be made available in earlier versions of PS: I expect some of them are binary addins rather than PS scripts - so upgrading the entire package just to get a couple of new cmdlets is a nuisance.
I've been using Powershell as my main interface on windows for a while now: it gives me the power I had with ksh and tools on Unix. It happily supports vi keybindings for searching/scrolling through history as well :-) I now do a lot of core work from that command line, even if it's ultimately to start a GUI app (it's much quicker for me to cd from the command line then start explorer than navigate via explorer). For those really annoying things, it's simple enough to create a script that emulates `grep` that takes -i and -r switches.
It's brought back the ease to use the system that I missed from my Unix days (when having a few xterms permanently open was the norm; I now do the same with Powershell).
For those dissing it and putting bash on a Windows box instead: that's not always going to work in corporate environment. Powershell comes pre-baked in so it's one less dependency to have to roll out, which is a win for deployment. For the same reason, I wouldn't insist on PS on Linux. However in a mixed-economy, you have the option to use whichever shell your comfortable with. For a Windows shop moving/experimenting with Linux, having the option to roll PS out means one set of deployment scripts can be ran on both systems (although deployment may be the least of the issues).
I don't see this as a Linux vs MS vs. rest-of-world. It's nice to see the choice. No-one is forcing anyone to use it :-) As others have said, it gives you a lot of power, but so do shell scripts or perl, and it's easy to write unwieldy scripts in all of these.
Cars are a good example IMO - there's a lot of software in them these days controlling the full driving experience. I have no idea how the engine management system in my car works, nor do I particularly need to know, but it's there to manage fuel consumption and emissions and make sure that the injectors open and close at the right instance squirting the right amount of fuel in. If the ECU or one of the sensors that feeds the ECU breaks, then the engine might fail, or emissions may go illegal and the little spanner lights on up the dashboard. It's this issue around the engine software that caused the large VW emissions fall-out.
Then there's all the other things (auto breaking, line detection warnings, auto parking, ...) that cars are increasingly able to do. Most of these probably don't have much complex choices in them, but we trust that they work, and can guess how they work (for each of the examples I gave, then that's radar, opto-electronics, and magic).
Some of these would be better made public (especially following the emissions scandal); but I can't see companies that have developed (say) auto-parking wanting to share their code as this removes a commercial advantage from rivals that don't have it. It's the sort of thing that could be shared at a broad level, but that probably wouldn't count for much and it's the detail that usually matters.
Does anyone know if there's ever been an attempt to force long term support through consumer rights? Could security bugs be classed as a defective product, giving (in theory) six years to claim. I don't know if there's any actual legal grounds for it, but it would be interesting to pursue, and would have the added benefit of making electronics firms take security seriously.
I'm curious: is there any chance that a claim against a product for having a fundamental security defect would fall foul of the CRA? Which describes it as "Under the Consumer Rights Act all products must be of satisfactory quality, fit for purpose and as described". I'd have thought defects fall foul of the first, and possibly the second (depending on the nature of the defect).
This probably has been discussed before, but my google-fu is failing me.
Devil's in the detail. It appears not every VS user gets Xamarin, despite the announcements and slides and everything else. Pulled the installer down to read the T&Cs and basically Community Edition users get a free-for-all, those VS users with Enterprise and Professional with an MSDN subscription get a free-for-all, but those organisations who Xamarin define as an enterprise who bought Enterprise or Professional without MSDN don't actually get a free-for-all: they're constrained to limited use (open source and education only).
Unless of course T&C's are yet to be updated. The implication though seemed to be that everything was available now from what I can tell from blog posts and everything else I've seen.
So useless for use on a train, or any other moving object where there's going to be varying background information?
I also recall reading a couple of years ago that virtual keyboards can actually be bad for joints: it was something to do with the shock travelling up the finger from repeatedly hitting a hard surface with the tip of the fingers, which normal keyboards don't have due to the cushioning of button presses. I've been trying to find the article again, but my google-fu's failing.
This is one of Tesla's tricks -- HV running at several kHz can travel through the body without the body feeling pain: at a high enough frequency, the electricty is only skin deep (literally) as it can't penetrate further.
One problem with this though is the body's nervous system doesn't respond quickly enough ... so even if it *should* hurt, it won't. So you can get burns, but it won't necessarialy kill you.
So I wouldn't call it "safe", and by virtue of its effects on the body, it may even be more dangerous because you won't immediately feel the effects. At least at 50Hz it's enough to make you notice when you've touched it ...
Can't really complain at that :-)
...but how are you going to prove that you suffered connection difficulties? What if your phone registered with a cell and then lost it again - can O2 tell from their logs if problems were outage related vs. something else? I work in an area where the O2 tower seems completely random, so used to reduced or no connectivity (some days I get HSPDA, other times lucky to get one bar and 3G; the joys of the countryside). Reserving judgement until the specifics of this are known...
Up to a point. It's also worth noting that if you *do* use MS's arbitration, then you don't have a subsequent appeal to the courts. See http://www.theregister.co.uk/2012/03/22/nominet_rules_mean_abusive_domain_name_registrations_finding_cannot_be_reheard_says_high_court/
Disclaimer -- no doubt I've missed a boat load of specifics out, edge cases, things that are or aren't included in that judgement that apply here...
Under "Desktop application development" it says:
"Visual Studio 11 Express for Windows 8 provides tools for Metro style app development. To create desktop apps, you need to use Visual Studio 11 Professional, or higher. In addition, Visual Studio 2010 Express products - Visual Basic 2010 Express, Visual C++ 2010 Express, and Visual C# 2010 Express - will remain available for free download. "
...that pretty much covers it.
The biggest problem I have with HTML5 on a professional level is that it's going to take a long time before there's enough push in the large public organisations that rely on IE to get a HTML5 capable browser rolled out. And this, unfortuantly, will always be the case. Whilst the public web can forge ahead at pace, companies can't keep up; some haven't even got a upgrade strategy for Windows 7 yet...
And this is what's ultimately going to keep the older technologies about: we have to develop software *now* for customers who aren't going to be upgrading any time soon, so we have to go with the older tech, no matter how much we'd like to forge forward with newer stuff. We've already had to do some back-testing on IE6 for one customer who didn't have an upgrade plan in place to roll out several thousand desktops with IE7... (let alone IE8...).
As long as the public sector drags it's feet, then the poorer some web-based intranet apps will be.
Another +1 for the Alpha here -- I was a placement student when I first came across DEC kit in the form of a DEC 3000 supporting a not insignificant development team. In a world of 32-bit, 64-bit seemed like the future :-) I now have a DEC 3000 acting as a monitor stand on my desk, but keep wondering what I could use it for if I powered it back up again...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
