I still have docs that refer to UCS-2 as 'Unicode encoding' (the options in that doc were ASCII or 'Unicode', which at the time confused me since I immediately thought '*which* unicode' until I realized the document in question hadn't been updated since 1995 and found out that back then there *wasn't* such a thing as alternative encodings of unicode.
As you can imagine, I learned way more than I ever wanted to know about the history of unicode trying to support those specifications.
That's been the frustrating thing with these shows, you never know which of these ideas actually end up for sale. Even when the company says "absolutely, positively this thing will ship in March", they often never are heard of again. Basically unless you've already seen it for sale, you can't bank on anything at these shows being real.
If you are constantly flipping between applications- stepping through code and seeing what happens on the application, for example, one monitor is a pain in the neck.
I would think this depends on the window manager being able to allow you to effectively partition the monitor real estate. I have 2 24" monitors, so it's not like any reasonable panel would supersede *those*, but 17.3" panels I could easily see being inferior to a single large wide display panel.
4.5 GHz is not only achievable, it's actually a speed i7-7700k will run stock, air-cooled in turbo mode. So 5GHz on Skylake would have been about a 20% improvement over stock, on Kaby Lake it's 10%.
Generally things like this are suggested as a way to reduce support/testing obligation.
On a less practical front, a lot of software orgs get downright *religious* about their 'new and improved way' and will counter productively screw over their existing offering to try to convert folks.
MS tends to support stuff forever (IE will *still* run ActiveX stuff if you try hard enough, and that's only as rough as it is because there are dire security motivations to kill it). I don't like their stuff and struggle daily with mistakes, but I can never accurately accuse them of prematurely killing support off of a technology (compared to say Google and Apple, who don't care).
Unix vendors are about the only game in town with a similarly spotless track record (RedHat arguably, though the 'backwards compatibility' of systemd has had a lot of problems. Also their rewrite of anaconda has been a bit of a mess for relatively little practical benefit, while MS has pretty much stuck with their now current installer since Vista, even though that's a nightmare of an installer).
I think powershell is a really awkward in-the-middle.
Yes, cmd is terrible. But powershell has issues 'scaling down'. It does a pretty good job, but pretty quickly some little quirk will pop up (like having to precede an invocation with '&' to disambiguate calling a command). Basically it's trying to provide a more capable language (more in the ballpark of python/perl/et al, but there are issues there I'll get to) but trying to be more bash-like. The issue is that no one has really done that, and powershell is no exception. A language focused on supervising external executables just has too tough a time also getting nice features and sanely presenting it all at once. Similarly, the object piping can't be the same between 'native' in-process code and legacy external executables, so you have another concept that presents subtle differences in certain scenarios despite looking the same on the face of it.
On the flip side, it's uglier than a lot of peer interpreted languages. Every time I'm put in a position to write something in powershell, I want to scream (which is better than cmd, which I just won't do, I'll use powershell or even vbs in such a case).
I'd normally be unambiguously agreeing with you, except that MS has been very explicit in their telemetry push. So yes, that statement by itself doesn't mean a company is spying, but there is a broader context where the spying is explicit.
Well, he was saying UTF-8 instead of UTF-16 (well UCS-2...) and UTF-16 has pretty much all the same drawbacks. Of course you said 32-bit but the parent was griping about UCS-2 so there we go.
While variable-length encoding has drawbacks, the problems are pretty well solved and baked into the fundamental portions of languages. Also, only really a challenge for initial import and final export of data, all processing of the data can be encoded in whatever way works best (e.g. I believe it's common for those languages/libraries to use a 32 bit encoding internally to make things easier. The penalty of wrangling variable length encoding on ingest is negligible (particularly compared with all sorts of other circumstances that are also likely to be in play.
I think the Powershell advocates would claim that the power of default carries cmd.
As you say, the security ambitions do a pretty good job of undermining powershell versus cmd. At the same time, cmd undermines the effectiveness of the security policy anyway, since cmd scripts can do whatever they want including making powershell work, so it's both annoying and pretty much useless on that front.
In general, I'd put PowerShell as a language in the neighborhood of Javascript, but with a less powerful syntax. It's amazingly annoying, easily can get into an unmaintanable mess, and yet requires you to 'step up' to C# to get to really useful syntax. Sure, they have a slick way of using.Net things which is really nice for that platform (python's ctypes aren't too shabby either, but compared to doing analogous effort with XS in perl, it is pretty nice).
On the second case, basically it was the opposite of the whole Itanium/Netburst debacle. When Intel did netburst and Itanium, doing exactly the wrong moves, AMD went ahead with AMD64 and good microarchitecture and AMD enjoyed superiority across the board until Intel Core, and retained some semblance of superiority on some front until Nehalem got everything togetehr.
Just as Intel got everything going with their system, AMD BullDozer was basically AMD's netburst. Betting on a concept that didn't pan out to claim big core counts when in fact it couldn't really perform at that level.
Actually, CMD would be in theoretically worse shape if evaluated apples to apples. However, powershell *puroports* to have security features like execution policies and signing, so it draws more scrutiny. Those are pretty much useless in practice because a cmd script is not subjected to that scrutiny and can just modify the executionpolicy of powershell at will if it really wanted to do some nefarious stuff that required powershell (though they could easily use pretty much any language they want).
Yeah, for various reasons I'm running CentOS, so contending with some gnarly ancient libraries. They provide a CentOS7 repo, but conflict with versions required by base content without using localized libraries, so the container approach is the shortest answer.
worse than HTTP because the latter is a transport layer only. All auth is accomplished through HTTPS.
Strictly speaking, he did say HTTP, which without TLS isn't any better. Of course there's nothing suggesting that HTTP without TLS would be open so it's a bit of a weird leap to make.
I will say in practice HTTPS on embedded IT equipment is only a little useful in most cases, since they have unverified certificates to kick things off. There are rare areas that bother to do proper certificates and/or rare software that gives self signed certs the appropriate treatment, but overwhelmingly people click on https and click through the warning which reduces https to http level security (anyone who can sniff is almost always in a position to inject themselves).
Yeah, I ended up just using their docker image. I would have preferred not to, but they don't manage their prereqs very well and end up wanting to install conflicting libraries. Still it's not too bad as it stands.
I use emby as my media server. It provides a shared point and tv/movie metadata and eyecandy like shots and all. Their frontend (and plex's) is not that good in my opinion.
Kodi is good when you are using a single system and that's it. There is hypothetically some semblance of shared library, but it's hard and doesn't work that well.
Right now I have mythtv (haven't found a better working PVR backend with scheduling) and emby for managing my video content at a central location and each TV and mobile device in the house pulls everything from that while running Kodi.
Plex Media server would be a relative resource hog when I tried it. That plus all the nickle and diming over plexpass made me go to an emby+kodi solution for that media.
Which is why it was a bad idea to do all that in the first place.
Now that it has happened, all the shareholder objections about how it wastes money previously spent is chasing sunk cost. Shareholders saying 'stay the course' are being fanatical about a failed goal.
The money is gone and it isn't coming back. Throwing more money at the problem is just making the money pit worse.
The problem here is the shareholders are being fanboys first and businessmen a distant distant second.
The evidence is overwhelming that MS Mobile platform just isn't going to happen. They've tried everything they could think of multiple times, and no signs that there is anything more they can realistically do and expect a difference. As such, they need to do what they can to be relevant to the large market that matters rather than staying in denial.
Besides, being in hardware is not that appealing. It's full of low cost competitors and very well known brands with insurmountable brand strength. It can be a decent enough strategy if you don't have any way in on the software front, but if you have strength in the software side, you have a lot more lucrative prospects than the hardware side.
In the desktop era, MS overcame the competition by being able to pit the suppliers of hardware against each other and control the 'good' bits. Apple's success in mobile distracted them from this reality, and Google then out-did microsoft in the 'license to OEMs' game (by being free or near free depending, and banking on ongoing revonue).
Of course, it's not python-esque, it's much worse. It reminds more more of javascript or perl, but with less power than either in terms of syntax (yes, feature wise you can access all kinds of.net functions, but structuring your pure powershell is very limited and the syntax can be very hard to maintain).
I never was a fan of the cygwin setup, I'm a much bigger fan of the way git for windows does bash. Then I don't have a distinct 'linux' environment from the 'native' environment.
As I said, "There are scenarios where that can make sense where the role of the device is very well defined (ATMs, Point of Sale equipment, etc)", which would include the IoT category. Note that no one is suggesting deploying antivirus onto those platforms, it would be a ridiculous concept.
Anti virus only makes sense on platforms that are open ended. To the extent you have more special purpose applications (document editors), then yes, the vendor should be held accountable for lazily allowing things that never made sense.
But for a general purpose computing device (personal desktops), at some point the user is going to make a decision to run or not run an application. The user needs to be educated to make the right call. If you say you shouldn't be in a situation where the users call could *possibly* be wrong, that means you aren't allowing the user to run applications they want.
Slashdot Mirror
I still have docs that refer to UCS-2 as 'Unicode encoding' (the options in that doc were ASCII or 'Unicode', which at the time confused me since I immediately thought '*which* unicode' until I realized the document in question hadn't been updated since 1995 and found out that back then there *wasn't* such a thing as alternative encodings of unicode.
As you can imagine, I learned way more than I ever wanted to know about the history of unicode trying to support those specifications.
That's been the frustrating thing with these shows, you never know which of these ideas actually end up for sale. Even when the company says "absolutely, positively this thing will ship in March", they often never are heard of again. Basically unless you've already seen it for sale, you can't bank on anything at these shows being real.
If you are constantly flipping between applications- stepping through code and seeing what happens on the application, for example, one monitor is a pain in the neck.
I would think this depends on the window manager being able to allow you to effectively partition the monitor real estate. I have 2 24" monitors, so it's not like any reasonable panel would supersede *those*, but 17.3" panels I could easily see being inferior to a single large wide display panel.
But would you be ok with the three monitors if they couldn't be moved vertically (just sitting *right* on the keyboard).
Also would you settle for 17.3" panels?
I'd rather have a single 27" panel than 3 17" panels, even ignoring the lack of a good stand.
It's way too awkward to be portable, and it's way too limited to credibly replace a desk setup.
4.5 GHz is not only achievable, it's actually a speed i7-7700k will run stock, air-cooled in turbo mode. So 5GHz on Skylake would have been about a 20% improvement over stock, on Kaby Lake it's 10%.
Generally things like this are suggested as a way to reduce support/testing obligation.
On a less practical front, a lot of software orgs get downright *religious* about their 'new and improved way' and will counter productively screw over their existing offering to try to convert folks.
MS tends to support stuff forever (IE will *still* run ActiveX stuff if you try hard enough, and that's only as rough as it is because there are dire security motivations to kill it). I don't like their stuff and struggle daily with mistakes, but I can never accurately accuse them of prematurely killing support off of a technology (compared to say Google and Apple, who don't care).
Unix vendors are about the only game in town with a similarly spotless track record (RedHat arguably, though the 'backwards compatibility' of systemd has had a lot of problems. Also their rewrite of anaconda has been a bit of a mess for relatively little practical benefit, while MS has pretty much stuck with their now current installer since Vista, even though that's a nightmare of an installer).
I think powershell is a really awkward in-the-middle.
Yes, cmd is terrible. But powershell has issues 'scaling down'. It does a pretty good job, but pretty quickly some little quirk will pop up (like having to precede an invocation with '&' to disambiguate calling a command). Basically it's trying to provide a more capable language (more in the ballpark of python/perl/et al, but there are issues there I'll get to) but trying to be more bash-like. The issue is that no one has really done that, and powershell is no exception. A language focused on supervising external executables just has too tough a time also getting nice features and sanely presenting it all at once. Similarly, the object piping can't be the same between 'native' in-process code and legacy external executables, so you have another concept that presents subtle differences in certain scenarios despite looking the same on the face of it.
On the flip side, it's uglier than a lot of peer interpreted languages. Every time I'm put in a position to write something in powershell, I want to scream (which is better than cmd, which I just won't do, I'll use powershell or even vbs in such a case).
I'd normally be unambiguously agreeing with you, except that MS has been very explicit in their telemetry push. So yes, that statement by itself doesn't mean a company is spying, but there is a broader context where the spying is explicit.
Well, he was saying UTF-8 instead of UTF-16 (well UCS-2...) and UTF-16 has pretty much all the same drawbacks. Of course you said 32-bit but the parent was griping about UCS-2 so there we go.
While variable-length encoding has drawbacks, the problems are pretty well solved and baked into the fundamental portions of languages. Also, only really a challenge for initial import and final export of data, all processing of the data can be encoded in whatever way works best (e.g. I believe it's common for those languages/libraries to use a 32 bit encoding internally to make things easier. The penalty of wrangling variable length encoding on ingest is negligible (particularly compared with all sorts of other circumstances that are also likely to be in play.
Well, strictly speaking, Unicode was there, but at first UCS-2 was 'the' unicode encoding.
I think the Powershell advocates would claim that the power of default carries cmd.
As you say, the security ambitions do a pretty good job of undermining powershell versus cmd. At the same time, cmd undermines the effectiveness of the security policy anyway, since cmd scripts can do whatever they want including making powershell work, so it's both annoying and pretty much useless on that front.
In general, I'd put PowerShell as a language in the neighborhood of Javascript, but with a less powerful syntax. It's amazingly annoying, easily can get into an unmaintanable mess, and yet requires you to 'step up' to C# to get to really useful syntax. Sure, they have a slick way of using .Net things which is really nice for that platform (python's ctypes aren't too shabby either, but compared to doing analogous effort with XS in perl, it is pretty nice).
Of course UTF-16 (or is it UCS-2 in cmd?) is an annoying encoding of unicode. It's variable length like UTF-8, but not ASCII compatible.
On the second case, basically it was the opposite of the whole Itanium/Netburst debacle. When Intel did netburst and Itanium, doing exactly the wrong moves, AMD went ahead with AMD64 and good microarchitecture and AMD enjoyed superiority across the board until Intel Core, and retained some semblance of superiority on some front until Nehalem got everything togetehr.
Just as Intel got everything going with their system, AMD BullDozer was basically AMD's netburst. Betting on a concept that didn't pan out to claim big core counts when in fact it couldn't really perform at that level.
Actually, CMD would be in theoretically worse shape if evaluated apples to apples. However, powershell *puroports* to have security features like execution policies and signing, so it draws more scrutiny. Those are pretty much useless in practice because a cmd script is not subjected to that scrutiny and can just modify the executionpolicy of powershell at will if it really wanted to do some nefarious stuff that required powershell (though they could easily use pretty much any language they want).
Yeah, for various reasons I'm running CentOS, so contending with some gnarly ancient libraries. They provide a CentOS7 repo, but conflict with versions required by base content without using localized libraries, so the container approach is the shortest answer.
worse than HTTP because the latter is a transport layer only. All auth is accomplished through HTTPS.
Strictly speaking, he did say HTTP, which without TLS isn't any better. Of course there's nothing suggesting that HTTP without TLS would be open so it's a bit of a weird leap to make.
I will say in practice HTTPS on embedded IT equipment is only a little useful in most cases, since they have unverified certificates to kick things off. There are rare areas that bother to do proper certificates and/or rare software that gives self signed certs the appropriate treatment, but overwhelmingly people click on https and click through the warning which reduces https to http level security (anyone who can sniff is almost always in a position to inject themselves).
Yeah, I ended up just using their docker image. I would have preferred not to, but they don't manage their prereqs very well and end up wanting to install conflicting libraries. Still it's not too bad as it stands.
It's not so kludgy really.
I use emby as my media server. It provides a shared point and tv/movie metadata and eyecandy like shots and all. Their frontend (and plex's) is not that good in my opinion.
Kodi is good when you are using a single system and that's it. There is hypothetically some semblance of shared library, but it's hard and doesn't work that well.
Right now I have mythtv (haven't found a better working PVR backend with scheduling) and emby for managing my video content at a central location and each TV and mobile device in the house pulls everything from that while running Kodi.
Plex Media server would be a relative resource hog when I tried it. That plus all the nickle and diming over plexpass made me go to an emby+kodi solution for that media.
Which is why it was a bad idea to do all that in the first place.
Now that it has happened, all the shareholder objections about how it wastes money previously spent is chasing sunk cost. Shareholders saying 'stay the course' are being fanatical about a failed goal.
The money is gone and it isn't coming back. Throwing more money at the problem is just making the money pit worse.
The problem here is the shareholders are being fanboys first and businessmen a distant distant second.
The evidence is overwhelming that MS Mobile platform just isn't going to happen. They've tried everything they could think of multiple times, and no signs that there is anything more they can realistically do and expect a difference. As such, they need to do what they can to be relevant to the large market that matters rather than staying in denial.
Besides, being in hardware is not that appealing. It's full of low cost competitors and very well known brands with insurmountable brand strength. It can be a decent enough strategy if you don't have any way in on the software front, but if you have strength in the software side, you have a lot more lucrative prospects than the hardware side.
In the desktop era, MS overcame the competition by being able to pit the suppliers of hardware against each other and control the 'good' bits. Apple's success in mobile distracted them from this reality, and Google then out-did microsoft in the 'license to OEMs' game (by being free or near free depending, and banking on ongoing revonue).
Yes, and rather than impreving the performance for real, they do things to try to cheat and cache.
Amazing given their situation that they are so much slower than any other scripted runtime to start.
Of course, it's not python-esque, it's much worse. It reminds more more of javascript or perl, but with less power than either in terms of syntax (yes, feature wise you can access all kinds of .net functions, but structuring your pure powershell is very limited and the syntax can be very hard to maintain).
I never was a fan of the cygwin setup, I'm a much bigger fan of the way git for windows does bash. Then I don't have a distinct 'linux' environment from the 'native' environment.
As I said, "There are scenarios where that can make sense where the role of the device is very well defined (ATMs, Point of Sale equipment, etc)", which would include the IoT category. Note that no one is suggesting deploying antivirus onto those platforms, it would be a ridiculous concept.
Anti virus only makes sense on platforms that are open ended. To the extent you have more special purpose applications (document editors), then yes, the vendor should be held accountable for lazily allowing things that never made sense.
But for a general purpose computing device (personal desktops), at some point the user is going to make a decision to run or not run an application. The user needs to be educated to make the right call. If you say you shouldn't be in a situation where the users call could *possibly* be wrong, that means you aren't allowing the user to run applications they want.