Isn't this whole bit about Google sabotaging Firefox performance, exactly the same thing we just heard from someone who used to be on the Microsoft Edge team?
At the time, folks around Slashdot were all like, "haw, haw, haw, karma's a bitch, eh there Billy?" Which is, of course, the easy and fun thing to say because of a predisposed hatred of Microsoft.
Now we see that Google has persistently been sabotaging Firefox as well. So maybe the problem wasn't Edge, after all.....
And given how many former Microsoft people are (or have been) at Google -- it's a four-digit number -- I'm really not surprised to see those sleazy late-90s Microsoft anticompetitive tactics show up once again.
Users need to update and Windows doesn't make that easy like linux distros do.
This isn't actually true with Windows 10. It does have a built-in package manager that is capable of installing & updating packages from Chocolatey, GitLab repositories, etc..... and it has the Microsoft Store, which has an auto-update mechanism and is perfectly capable of supporting classic Win32 programs like WinRAR, including the command-line version. (Yes, console apps in the MS Store is a thing nowadays.)
Problem is.... nobody really seems to know any of this. This is mostly Microsoft's fault since they rarely talk about anything other than superficial improvements in Windows 10.... and because telemetry & update policies have kept a ton of people on Windows 7 (despite the upgrade being free) so software developers haven't been especially motivated to take full advantage of Windows 10 features and deployment techniques.
A Store App version of WinRAR would actually be mostly invulnerable to these attack vectors because the app containers which they run in aren't allowed to write to the "Startup" folder in the user's profile. Anything other than Documents, Downloads, Desktop, etc. requires explicit access, controllable via the Privacy settings page. On top of all that, the authors want to charge $29 for WinRAR.... wouldn't publishing to the store be a useful way of getting some more people to pay?
You mean unique software. Apple is at its core a software company. This seems counter-intuitive until you think about it for a minute. The hardware in most Apple devices is at best superficially different from the competition and Apple doesn't even manufacture it. Oh they make a big stink about their design as a marketing ploy but it isn't what really makes their products distinct. You can (and I have) put Windows on a Macintosh and the experience is not meaningfully different than on a Dell or HP. Apple differentiates their products primarily through their software. If a Macintosh was sold with Windows they would be unable to command the profit margins they currently do because their hardware is nice but it's not that different or better than their best competition.
This theory ignores the fact that the primary attraction for many Mac users, especially web developers and science/engineering types, is the POSIX underpinnings and the GNU toolchain. Apple did not create POSIX or GNU and do not substantially contribute to the development to them. Their support of CUPS and Clang is welcome and appreciated, and they recently open-sourced FoundationDB, which is nice if Cassandra isn't small-batch-craft-beer-check-shirt enough for your hipster ass..... but.... what else do they do in this space? Almost 100% of people working in these fields could use Linux instead, but they choose macOS because of the well-polished hardware integration, especially the screens, keyboards (maybe less so now) and touchpad.
Yes, there was a period where Apple was well-defined by great software: The early-mid 2000's. Programs like iPhoto, Garageband, and iMovie cemented their reputation as a company that could create really innovative software that was really easy to use. But that's a long, long time ago now. Here's the reality: There has been exactly one entirely new Mac application from Apple this entire decade. Yes, just one, and you'd never guess it: iBooks Author. That's it. Everything else they've done has been iterating on products from the Steve Jobs era (Mainstage, Motion, iTunes), or doing mediocre ports of mediocre iOS apps, like Homekit and Stocks. Whoop-dee-fucking-doo. Nobody's buying a Mac instead of a Surface because it can run desktop versions of mobile apps.
Apple isn't exactly the gold standard in pro software either. Most software devs don't love XCode.... Final Cut Pro X isn't capturing converts from Premiere.... Logic is very good but ProTools is still the industry standard.... tons of people choose Office over Pages, Sheets, Keynote and Mail.... Safari is generally considered inferior to Firefox and Chrome....
Add to that the fact that almost nobody can name a new feature of Mojave other than Dark Mode.... it sure feels like Apple is coasting on their Mac software efforts, not leading.
I know it's fun and exciting to blame a web browser hotfix for a booting problem..... especially when it's Internet Explorer, right? But..... ahhh, shit, hate to spoil the fun, but this is just another case of "journalists" not doing the bare minimum of reading before shitting out another article they'll get paid $10 for.
This booting problem with Lenovo laptops has existed for a month and a half -- it was introduced in the November 2018 cumulative security update. It even says so right there in the patch notes! But because these "journalists" don't know how to read anymore, we end up with Slashdot articles like this one that don't have the correct information in them.
All Windows patches are now cumulative, so sure, if you apply the IE hotfix to a machine that is three months behind in updates, then you can hit this problem. But it's not the IE part that's causing it.
A lot of people around here don't keep up with Microsoft technology, so here's a few notes and caveats:
1. The Windows and Mac versions of Visual Studio 2019 are completely separate products built from different code bases. They share compilers and.NET Core stuff, and a lot of work is going into making the editors feel the same. But you can't actually use Visual Studio for Mac to work on classic Win32 /.NET Framework applications.
2. Windows Forms and WPF are also Windows-only technology, and that isn't changing even though they'll work with.NET Core 3. There are way too many hooks and dependencies on Windows-specific technology (e.g. DirectX, text rendering, themes, handles) for these to be made into cross-platform applications without major rearchitecting work. In other words, don't wait up for them to produce a competitor to Qt....
3. The source code for Windows Forms and WPF have actually been available as "reference source" for more than a decade, so there are no real surprises to be discovered here.
4. All three libraries are being hosted on Github and are licensed under MIT. These aren't mirrors -- the teams at Microsoft will actually be doing their everyday work in the open on Github. Unfortunately, the full commit history didn't come along for the ride.
5. One of the nice little improvements here is the ability to package your own version of Windows Forms with your app, instead of relying on whatever is installed with the system..NET Core doesn't (currently) support static linking so it'll still have to exist as a DLL file beside the EXE.
Get rid of the bloody framework. Why include 200K of compressed javascript when you're only going to use two five-line functions.
Not to mention all the potential security vulnerabilities you just needlessly included in your code.
Always blows me away when developers draw the line at "Javascript frameworks".
Never mind the dependency on several different web browsers, each of which are loaded with thousands of capabilities, but behave a little different from eachother. Never mind the hard dependency on a mediocre programming language that changes frequently, cannot be compiled ahead of time, must be served in an inefficient text format, and whose corresponding graphical assets must be sent across the Internet every time the user wants to see them. Never mind the fact that we have to use transpilers like babel or Typescript, minifiers, packaging & loader engines like webpack or SystemJS, polyfills to cover older browsers..... Never mind the fact that there was NO STANDARD LIBRARY for most of JavaScript's existence...... never mind the fact that we have to slow everything down on the server -and- client side because we have to use HTTPS to protect our application at runtime. No, let's not blame all that, let's blame Lodash, Sizzle, Wolkenkit, Redux and SignalR for having the temerity to exist and be useful to developers.
Makes no sense, dude. Makes no sense at all.
Take this Slashdot page I'm looking at right now. According to Firefox's own dev tools, this Slashdot browser tab I'm typing in is taking 150 MB RAM, but just 22 MB of that is actually for the page's content and scripts. The addition or removal of some JavaScript isn't going to make a big difference here!
Dumb. Lawyers exists because they are the "engineers" of the law, and know how it works (inside and out). It is ridiculous to try to do a job where you have zero experience.
You know what's really weird? The guy's reasons for representing himself:
1) He has no money because he hasn't worked since 2014, and
2) His attorney had a stroke, and he can't afford another one
Okay, yeah, maybe finding new work might be a little difficult if you were just fired from Apple after working there for 8 years for unprofessional conduct, but..... four years of unemployment? Come on. If you're an engineer who's good at what they do, and you live in Northern California as he does, surely you should be able to get a new job.
You provide a lot of what-ifs, but leave out the most important one: what if Adobe developers were at least remotely competent at cross-platform development, and created an actual API that they would code to. Implement that API once across each supported platform, then stop worrying about it. That's cross-platform development tutorial #1.
This isn't a "cross-platform development" issue, this is an "older operating systems are missing features that will help us make better software" issue.
In Adobe's case, OS X El Capitan is the first version to support Metal -- this API is much more efficient on systems with multiple CPU cores. Windows 10 is the first version to support DirectX 12, which opens op the capability of using multiple discrete GPUs for rendering tasks on Windows. There is no "cross-platform" or "backwards-compatible" way of doing these kinds of things -- all applications, including your mythical compatibility layer, will depend on the low-level graphics capabilities of the operating systems they use. It's completely unreasonable to expect Adobe to reimplement core OS features just to appease some technological refuseniks who prefer decade-old operating systems for aesthetic or emotional reasons.
And look, I get it, people don't like Windows 10 because they've bought into the hype that it's a "spying operating system". Yes, it sends a list of your installed apps to Microsoft, but they do that so you won't receive Windows Updates with known compatibility issues. And yes, it's measuring how long certain operations take, like opening the Settings app, but they do that so that Microsoft can prioritize performance improvements.
As for Apple, yes, macOS High Sierra has been the worst Mac OS release in over a decade, and macOS Mojave is shortening the leash on supported hardware range for Macs to 6-7 years, and it's removing features that people actually use like Back To My Mac... it's really super-frustrating.
But here's the thing: both operating systems also continue to add very useful programming APIs for developers so that they can continue to improve their software. The next update to Windows 10 is finally adding native Unix-style ptys, for instance, and the console natively supports xterm-256color. Mojave, for its part, is finally implementing the OpenType-SVG font standard, i.e. fonts with colour. Maybe these don't interest you, but there's literally thousands of low-level improvements like these over the last several years, many of which would make your computing life nicer.
But if you don't know about those things, and make personal computing choices based solely on press negativity, you'll never get to learn about, much less enjoy the upsides.
The best way to make CMD livable is to install Take Command. I've been using it since it was called 4DOS back in the pre-Windows days. It has always provided tab filename completion, history, etc (all those nice things in bash) and a much larger command set.
Why are you still using CMD in 2018? Why should anyone pay $100 per computer for the closed-source, proprietary Take Command when they could learn Powershell instead? Powershell has full Intellisense nowadays, access to the full.NET Framework library, comprehensive built-in documentation, and thousands of commands that can reach into every part of the system. Plus Powershell is an open-source Github project nowadays. Pair it with the open-source ConEmu for a wicked-good, fully configurable console environment.
Next I would like to see Microsoft make CLI versions of all the traditional windows management tools, and
then for legacy GUI tools
Your wish has been granted.... like.... nine years ago. Where've you been, dude and/or dudette? As a random example: Microsoft added Managed Service Accounts in 2008 R2, and you can see a "Managed Service Accounts" folder in AD Users and Computers, but you cannot create or edit them there. You -must- do it through Powershell using New-ADServiceAccount. Here's a blog post from 2009 on the subject.
Pretty much the only parts of Windows you can't configure through the command prompt, are some of the GUI elements. For example, there is no way to change what is pinned to the taskbar, nor can you programmatically set whether a tray icon will always be visible or not. Folks at Microsoft have said that this limitation is intended to protect the user from app installers that inject themselves all over the place. Setting crucial visual things like display resolution is also disallowed (except on Server Core, where there is no GUI to do this).
Yes, having no Internet access is a bad deal for Virginians, but maybe the state representative should be doing something about that instead of bitching to Amtrak.
Have you even been to West Virginia? High-speed internet service is a major technical challenge there because of the geography. It's really mountainous and sparsely-populated. You can barely even get 3G service outside the cities unless you're near an Interstate or state highway. Good places to put towers that effectively cover a large area few and far between.
On top of that, there is a complete lack of cell service, Wi-fi or even microwaves on the central-eastern side of the state because of the Green Bank Observatory. (If you don't know about this, read up on it because it's actually really interesting.)
I think us lower UIDs, who have a solid memory of Hitler, Stalin, Mao, remember that spying w
WHOAH, whoah, hold up a second there dude.... all I have a solid memory of is a Beowulf cluster of hot grits, served up by a petrified Natalie Portman!
And none of this modern shit.... give those little snots Version 2.1 on 70 floppy disks! Thatâ(TM)ll showâ(TM)em!
If I had to struggle as a youth to learn Linux, so should everyone!!
I imagine the inability of third party cloud storage apps is a "flaw" that won't be fixed any time soon. Sorry Dropbox and google Drive, you're out.
No, no, no. It's a technical limitation of emulation, not some kind of insidious plan to block out competition.
Windows 10 on ARM supports shell extensions just fine -- the vendors have to recompile their applications is all. Nothing Mac OS developers didn't go through during the PPC -> Intel transition twelve years ago.
Literally anyone who's written shell extensions for Windows Explorer before will already understand the problem: shell extensions are loaded into the same process as Windows Explorer itself. Loading x86 code into a process that's running native ARM code just isn't going to work.... lots of issues that are pretty much impossible to work around, like calling conventions, endianness, memory layout, ASLR implementation.... all sorts of fun things. How would you even get an x86 emulator to pick and choose when to kick in? Based on memory ranges of loaded DLLs? No way -- you don't want that kind of voodoo horseshit going on in your apps, especially Windows Explorer, whose extensibility model is already pretty rickety as it is.
This is what happens when you pick technologies by popularity and groupthink. Git has very real flaws: the worst UI of any source control system I've ever used,
Whoah, whoah, whoah, now wait a sec here. We're talking about a program invented by Linus Torvalds, the creator of a kernel that routinely sits under userlands where a synonym of "feline" prints the contents of files, where a household cleaner (vim) is a text editor, where "more" and "less" do the same thing despite being literal opposites, and where sometimes, but not always, parameter names are case-sensitive (rm -r == rm -R but rm -i != rm -I).
So of course git is hard to learn. Just like Linux itself, it makes you fucking work for it.... but then it pays you back a thousand times over. I'm not going to try to convince you that git is the best source control solution out there, but boy oh boy can you ever do a lot with it once you understand its mental model.
It's not much use until the vast majority of users have adopted these compatible browser versions.
Not being intentionally negative, but how long will this take in reality?
Not long.
caniuse.com says that 67% of browsers currently in use in North America support WebAssembly. The 33% breaks down like this: 10% iOS 9/10, 6% IE, 4% Edge, 3% Samsung browsers, and 10% for every other rickety thing out there.
Give iOS 10 -> 11, Safari 10 -> 11, and Edge 15 -> 16 upgrades another 3 months to roll through (these are all safe and good-quality updates), then WebAssembly availability will be over 80%. That's good enough to take a dependency on. Millions of people keep on using IE, Android Browser and Opera Mini, which aren't getting any updates at all, and nearly 100% of those people have access to another device or browser which does support WebAssembly.
I know a lot of people have already checked out because they didn't like being sold a bill of goods. I totally understand those people. But for the rest of us who just want good games to play and don't care about the release-time controversy, it's looks like there's a better future coming. Hello Games has now added three major elements that were never announced or even hinted at prior to the original release: Land vehicles, base building, and now terraforming. Were these planned all along? Maybe, maybe not, but it's clear that more content and features will continue to be released.
For all we know, NMS will become a continually-evolving game like Eve Online, Elite: Dangerous, or even Starbound.
His Slashdot UID indicates he joined this site significantly earlier than me - and I was here in 2003. Are you suggesting he signed up in utero?
I've been reading Slashdot since late 1998. By March 2000 the signal:noise ratio in the comments was getting pretty intolerable, so I created an account and set my minimum reading level to 3. 17+ years later, that filter keeps on serving its purpose, dutifully hiding comments from people calling me a "millennial" because I had the audacity to stand up for enjoying what I've been paid to do for the last 30 years.
The work that software developers do is extremely mentally challenging. We're often under pressure to not only create a product that is good enough to be profitable (or at least helpful), but also to not make extremely subtle mistakes that results in security vulnerabilities, information exposure, or denial of service.
That's why we like putting little jokes in our software. It helps us cope with the pressure. It's why song lyrics, movie quotes and ASCII art find their way into code comments. It's why JIRA's about page is presented as an 8-bit video game. It's why we have an RFC describing an "evil bit". It's why error pages for popular source code repository have anthropomorphic robots. Hell, even MS Excel had a freakin' flight simulator built into it at one point!
The world is bad enough as it is without the misery-mongers demanding we excise all forms of fun from our line of work. Leave us alone. Let us have our fun. We know what we're doing.
- Visual Studio and TFS already have full CLI, GUI, and web-based support for Git. No such tooling exists for Mercurial.
- Microsoft has contributed to libgit2 for years.
- Mercurial is written in Python -- it's a small thing, but it's one more thing for a dev to maintain on their system.
- Git is easier to hire for.
You can also make the argument that Git was designed from the beginning to be suitable for developing an operating system. Or, put more bluntly, it was designed to be used by programmers who are smart enough to work on an operating system, Yes, the Mercurial CLI is generally easier to come to grips with, but that isn't a compelling enough reason on its own.
Keep in mind also that the overall direction of Mercurial is increasingly being driven by the needs of Facebook's dev teams. Which is great to see, in the sense that they're returning their enhancements to the community..... but by and large they're building web properties, not operating systems, so the priorities may be different.
Microsoft are just getting efficient. They have simply skipped "Embrace".
No they didn't. For one thing, Git has been supported in TFS for four years now. And then there's this:
"Among them, we learned the Git server has to be smart. It has to pack the Git files in an optimal fashion so that it doesn’t have to send more to the client than absolutely necessary – think of it as optimizing locality of reference. So we made lots of enhancements to the Team Services/TFS Git server. We also discovered that Git has lots of scenarios where it touches stuff it really doesn’t need to. This never really mattered before because it was all local and used for modestly sized repos so it was fast – but when touching it means downloading it from the server or scanning 6,000,000 files, uh oh. So we’ve been investing heavily in is performance optimizations to Git. Many of them also benefit “normal” repos to some degree but they are critical for mega repos. We’ve been submitting many of these improvements to the Git OSS project and have enjoyed a good working relationship with them."
But if multiple applications in Office share a library, where do you put that library so that the build process for each Office application can see it? Are submodules or subtrees a good choice, and if "yes," which is more appropriate?
Microsoft experimented with the submodules approach for Windows. Didn't work:
"We started down at least 2 failed paths to scale Git. Probably the most extensive one was to use Git submodules to stitch together lots of repos into a single “super” repo. I won’t go into details but after 6 months of working on that we realized it wasn’t going to work – too many edge cases, too much complexity and fragility. We needed a bulletproof solution that would be well supported by almost all Git tooling."
Yeah, Adobe. Just finished dealing with them this morning. And by "finished", I mean finished.
I just set up a Mac with MacOS Sierra 10.12, and attempted to install my copy of Photoshop CS5. Sierra advised me to throw the installer in the trash. Seriously. That's the dialog I got. Adobe "support" told me "not compatible with 10.12", and also "there is no fix or upgrade" other than enter into a permanent wallet-sucking fest for their "subscription" based product. No. Not a chance.
I hear your frustration, but don't lose sight of the fact that this is actually on Apple for failing to ensure their operating system is compatible with some of its most commonly-used products.
Back in the day, the Classic -> 10 and PPC -> Intel transitions were pitched to us as necessary one-time jumps to ensure the future health of the Mac. And we could accept it because we could see that we were talking about fundamentally different operating systems and fundamentally different hardware architectures. There's no justification for Mac OS X 10.6 software not working on macOS 10.12... they aren't fundamentally different. For the most part, it's just some API differences. Apple just doesn't really give a shit about backwards compatibility, simple as that.
Also, it has to be said: Adobe CS5 is known to work on the latest versions of Windows 10 with the exception of Premiere. Microsoft sinks a lot of time and effort into ensuring software that runs on Windows 7 continues to do so under Windows 10.
Sure. It's already there. Just gotta understand how Microsoft versions Windows now.
- Think of "Windows 10" as a brand name, like "Mac OS X", instead of "the tenth version of Windows".
- Run this from Powershell: get-item 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\' and you will see values like CurrentVersion (6.3), ReleaseId (1507, 1511 or 1607), CurrentBuild (10240, 10586 or 14393), and UBR (17113, 589 or 189 if you're fully patched)
- You can also see those numbers by typing "winver".
- ReleaseId and CurrentBuild will always be matched in any OS release. ReleaseId is the year/month; CurrentBuild is from their build system.
- UBR is short for UpdateBuildRevision and it generally refers to the number of bugfixes applied on top of CurrentBuild. It jumps by a bunch every time a cumulative updated is released.
- The CurrentVersion value of "6.3" might make you think that this is the fourth version based on the Windows Vista (6.0) kernel, but the reality is that they found a lot of software refuses to install if they try to increment it past 6, even if the software itself works perfectly on the newer version of Windows. So they deprecated this value in Windows 8.1 and it will always be 6.3.
(TL;DR: Mac OS X 10.11.6 == Windows 10 10.10586.589.)
Microsoft publishes a list of the cumulative fixes for Windows 10 and their Build/UBR numbers on their web site. They've never done this kind of a list for previous versions of Windows.
Slashdot Mirror
Isn't this whole bit about Google sabotaging Firefox performance, exactly the same thing we just heard from someone who used to be on the Microsoft Edge team?
At the time, folks around Slashdot were all like, "haw, haw, haw, karma's a bitch, eh there Billy?" Which is, of course, the easy and fun thing to say because of a predisposed hatred of Microsoft.
Now we see that Google has persistently been sabotaging Firefox as well. So maybe the problem wasn't Edge, after all.....
And given how many former Microsoft people are (or have been) at Google -- it's a four-digit number -- I'm really not surprised to see those sleazy late-90s Microsoft anticompetitive tactics show up once again.
Users need to update and Windows doesn't make that easy like linux distros do.
This isn't actually true with Windows 10. It does have a built-in package manager that is capable of installing & updating packages from Chocolatey, GitLab repositories, etc..... and it has the Microsoft Store, which has an auto-update mechanism and is perfectly capable of supporting classic Win32 programs like WinRAR, including the command-line version. (Yes, console apps in the MS Store is a thing nowadays.)
Problem is.... nobody really seems to know any of this. This is mostly Microsoft's fault since they rarely talk about anything other than superficial improvements in Windows 10.... and because telemetry & update policies have kept a ton of people on Windows 7 (despite the upgrade being free) so software developers haven't been especially motivated to take full advantage of Windows 10 features and deployment techniques.
A Store App version of WinRAR would actually be mostly invulnerable to these attack vectors because the app containers which they run in aren't allowed to write to the "Startup" folder in the user's profile. Anything other than Documents, Downloads, Desktop, etc. requires explicit access, controllable via the Privacy settings page. On top of all that, the authors want to charge $29 for WinRAR.... wouldn't publishing to the store be a useful way of getting some more people to pay?
You mean unique software. Apple is at its core a software company. This seems counter-intuitive until you think about it for a minute. The hardware in most Apple devices is at best superficially different from the competition and Apple doesn't even manufacture it. Oh they make a big stink about their design as a marketing ploy but it isn't what really makes their products distinct. You can (and I have) put Windows on a Macintosh and the experience is not meaningfully different than on a Dell or HP. Apple differentiates their products primarily through their software. If a Macintosh was sold with Windows they would be unable to command the profit margins they currently do because their hardware is nice but it's not that different or better than their best competition.
This theory ignores the fact that the primary attraction for many Mac users, especially web developers and science/engineering types, is the POSIX underpinnings and the GNU toolchain. Apple did not create POSIX or GNU and do not substantially contribute to the development to them. Their support of CUPS and Clang is welcome and appreciated, and they recently open-sourced FoundationDB, which is nice if Cassandra isn't small-batch-craft-beer-check-shirt enough for your hipster ass..... but.... what else do they do in this space? Almost 100% of people working in these fields could use Linux instead, but they choose macOS because of the well-polished hardware integration, especially the screens, keyboards (maybe less so now) and touchpad.
Yes, there was a period where Apple was well-defined by great software: The early-mid 2000's. Programs like iPhoto, Garageband, and iMovie cemented their reputation as a company that could create really innovative software that was really easy to use. But that's a long, long time ago now. Here's the reality: There has been exactly one entirely new Mac application from Apple this entire decade. Yes, just one, and you'd never guess it: iBooks Author. That's it. Everything else they've done has been iterating on products from the Steve Jobs era (Mainstage, Motion, iTunes), or doing mediocre ports of mediocre iOS apps, like Homekit and Stocks. Whoop-dee-fucking-doo. Nobody's buying a Mac instead of a Surface because it can run desktop versions of mobile apps.
Apple isn't exactly the gold standard in pro software either. Most software devs don't love XCode.... Final Cut Pro X isn't capturing converts from Premiere.... Logic is very good but ProTools is still the industry standard.... tons of people choose Office over Pages, Sheets, Keynote and Mail.... Safari is generally considered inferior to Firefox and Chrome....
Add to that the fact that almost nobody can name a new feature of Mojave other than Dark Mode.... it sure feels like Apple is coasting on their Mac software efforts, not leading.
I know it's fun and exciting to blame a web browser hotfix for a booting problem..... especially when it's Internet Explorer, right? But..... ahhh, shit, hate to spoil the fun, but this is just another case of "journalists" not doing the bare minimum of reading before shitting out another article they'll get paid $10 for.
This booting problem with Lenovo laptops has existed for a month and a half -- it was introduced in the November 2018 cumulative security update. It even says so right there in the patch notes! But because these "journalists" don't know how to read anymore, we end up with Slashdot articles like this one that don't have the correct information in them.
All Windows patches are now cumulative, so sure, if you apply the IE hotfix to a machine that is three months behind in updates, then you can hit this problem. But it's not the IE part that's causing it.
A lot of people around here don't keep up with Microsoft technology, so here's a few notes and caveats:
1. The Windows and Mac versions of Visual Studio 2019 are completely separate products built from different code bases. They share compilers and .NET Core stuff, and a lot of work is going into making the editors feel the same. But you can't actually use Visual Studio for Mac to work on classic Win32 / .NET Framework applications.
2. Windows Forms and WPF are also Windows-only technology, and that isn't changing even though they'll work with .NET Core 3. There are way too many hooks and dependencies on Windows-specific technology (e.g. DirectX, text rendering, themes, handles) for these to be made into cross-platform applications without major rearchitecting work. In other words, don't wait up for them to produce a competitor to Qt....
3. The source code for Windows Forms and WPF have actually been available as "reference source" for more than a decade, so there are no real surprises to be discovered here.
4. All three libraries are being hosted on Github and are licensed under MIT. These aren't mirrors -- the teams at Microsoft will actually be doing their everyday work in the open on Github. Unfortunately, the full commit history didn't come along for the ride.
5. One of the nice little improvements here is the ability to package your own version of Windows Forms with your app, instead of relying on whatever is installed with the system. .NET Core doesn't (currently) support static linking so it'll still have to exist as a DLL file beside the EXE.
Get rid of the bloody framework. Why include 200K of compressed javascript when you're only going to use two five-line functions.
Not to mention all the potential security vulnerabilities you just needlessly included in your code.
Always blows me away when developers draw the line at "Javascript frameworks".
Never mind the dependency on several different web browsers, each of which are loaded with thousands of capabilities, but behave a little different from eachother. Never mind the hard dependency on a mediocre programming language that changes frequently, cannot be compiled ahead of time, must be served in an inefficient text format, and whose corresponding graphical assets must be sent across the Internet every time the user wants to see them. Never mind the fact that we have to use transpilers like babel or Typescript, minifiers, packaging & loader engines like webpack or SystemJS, polyfills to cover older browsers..... Never mind the fact that there was NO STANDARD LIBRARY for most of JavaScript's existence...... never mind the fact that we have to slow everything down on the server -and- client side because we have to use HTTPS to protect our application at runtime. No, let's not blame all that, let's blame Lodash, Sizzle, Wolkenkit, Redux and SignalR for having the temerity to exist and be useful to developers.
Makes no sense, dude. Makes no sense at all.
Take this Slashdot page I'm looking at right now. According to Firefox's own dev tools, this Slashdot browser tab I'm typing in is taking 150 MB RAM, but just 22 MB of that is actually for the page's content and scripts. The addition or removal of some JavaScript isn't going to make a big difference here!
Dumb. Lawyers exists because they are the "engineers" of the law, and know how it works (inside and out). It is ridiculous to try to do a job where you have zero experience.
You know what's really weird? The guy's reasons for representing himself:
1) He has no money because he hasn't worked since 2014, and
2) His attorney had a stroke, and he can't afford another one
Okay, yeah, maybe finding new work might be a little difficult if you were just fired from Apple after working there for 8 years for unprofessional conduct, but..... four years of unemployment? Come on. If you're an engineer who's good at what they do, and you live in Northern California as he does, surely you should be able to get a new job.
Software engineer / developer here. I can.
You provide a lot of what-ifs, but leave out the most important one: what if Adobe developers were at least remotely competent at cross-platform development, and created an actual API that they would code to. Implement that API once across each supported platform, then stop worrying about it. That's cross-platform development tutorial #1.
This isn't a "cross-platform development" issue, this is an "older operating systems are missing features that will help us make better software" issue.
In Adobe's case, OS X El Capitan is the first version to support Metal -- this API is much more efficient on systems with multiple CPU cores. Windows 10 is the first version to support DirectX 12, which opens op the capability of using multiple discrete GPUs for rendering tasks on Windows. There is no "cross-platform" or "backwards-compatible" way of doing these kinds of things -- all applications, including your mythical compatibility layer, will depend on the low-level graphics capabilities of the operating systems they use. It's completely unreasonable to expect Adobe to reimplement core OS features just to appease some technological refuseniks who prefer decade-old operating systems for aesthetic or emotional reasons.
And look, I get it, people don't like Windows 10 because they've bought into the hype that it's a "spying operating system". Yes, it sends a list of your installed apps to Microsoft, but they do that so you won't receive Windows Updates with known compatibility issues. And yes, it's measuring how long certain operations take, like opening the Settings app, but they do that so that Microsoft can prioritize performance improvements.
As for Apple, yes, macOS High Sierra has been the worst Mac OS release in over a decade, and macOS Mojave is shortening the leash on supported hardware range for Macs to 6-7 years, and it's removing features that people actually use like Back To My Mac... it's really super-frustrating.
But here's the thing: both operating systems also continue to add very useful programming APIs for developers so that they can continue to improve their software. The next update to Windows 10 is finally adding native Unix-style ptys, for instance, and the console natively supports xterm-256color. Mojave, for its part, is finally implementing the OpenType-SVG font standard, i.e. fonts with colour. Maybe these don't interest you, but there's literally thousands of low-level improvements like these over the last several years, many of which would make your computing life nicer.
But if you don't know about those things, and make personal computing choices based solely on press negativity, you'll never get to learn about, much less enjoy the upsides.
The best way to make CMD livable is to install Take Command. I've been using it since it was called 4DOS back in the pre-Windows days. It has always provided tab filename completion, history, etc (all those nice things in bash) and a much larger command set.
Why are you still using CMD in 2018? Why should anyone pay $100 per computer for the closed-source, proprietary Take Command when they could learn Powershell instead? Powershell has full Intellisense nowadays, access to the full .NET Framework library, comprehensive built-in documentation, and thousands of commands that can reach into every part of the system. Plus Powershell is an open-source Github project nowadays. Pair it with the open-source ConEmu for a wicked-good, fully configurable console environment.
Next I would like to see Microsoft make CLI versions of all the traditional windows management tools, and then for legacy GUI tools
Your wish has been granted.... like.... nine years ago. Where've you been, dude and/or dudette? As a random example: Microsoft added Managed Service Accounts in 2008 R2, and you can see a "Managed Service Accounts" folder in AD Users and Computers, but you cannot create or edit them there. You -must- do it through Powershell using New-ADServiceAccount. Here's a blog post from 2009 on the subject.
Pretty much the only parts of Windows you can't configure through the command prompt, are some of the GUI elements. For example, there is no way to change what is pinned to the taskbar, nor can you programmatically set whether a tray icon will always be visible or not. Folks at Microsoft have said that this limitation is intended to protect the user from app installers that inject themselves all over the place. Setting crucial visual things like display resolution is also disallowed (except on Server Core, where there is no GUI to do this).
Yes, having no Internet access is a bad deal for Virginians, but maybe the state representative should be doing something about that instead of bitching to Amtrak.
Have you even been to West Virginia? High-speed internet service is a major technical challenge there because of the geography. It's really mountainous and sparsely-populated. You can barely even get 3G service outside the cities unless you're near an Interstate or state highway. Good places to put towers that effectively cover a large area few and far between.
On top of that, there is a complete lack of cell service, Wi-fi or even microwaves on the central-eastern side of the state because of the Green Bank Observatory. (If you don't know about this, read up on it because it's actually really interesting.)
I think us lower UIDs, who have a solid memory of Hitler, Stalin, Mao, remember that spying w
WHOAH, whoah, hold up a second there dude.... all I have a solid memory of is a Beowulf cluster of hot grits, served up by a petrified Natalie Portman!
And none of this modern shit.... give those little snots Version 2.1 on 70 floppy disks! Thatâ(TM)ll showâ(TM)em! If I had to struggle as a youth to learn Linux, so should everyone!!
Microsoft downgraded the bug's severity because exploiting it requires either physical access or social engineering (tricking the user).
So physical access and social engineering aren't problems now?
Theft and idiocy are not things that can be fixed with software updates.
I imagine the inability of third party cloud storage apps is a "flaw" that won't be fixed any time soon. Sorry Dropbox and google Drive, you're out.
No, no, no. It's a technical limitation of emulation, not some kind of insidious plan to block out competition.
Windows 10 on ARM supports shell extensions just fine -- the vendors have to recompile their applications is all. Nothing Mac OS developers didn't go through during the PPC -> Intel transition twelve years ago.
Literally anyone who's written shell extensions for Windows Explorer before will already understand the problem: shell extensions are loaded into the same process as Windows Explorer itself. Loading x86 code into a process that's running native ARM code just isn't going to work.... lots of issues that are pretty much impossible to work around, like calling conventions, endianness, memory layout, ASLR implementation.... all sorts of fun things. How would you even get an x86 emulator to pick and choose when to kick in? Based on memory ranges of loaded DLLs? No way -- you don't want that kind of voodoo horseshit going on in your apps, especially Windows Explorer, whose extensibility model is already pretty rickety as it is.
This is what happens when you pick technologies by popularity and groupthink. Git has very real flaws: the worst UI of any source control system I've ever used,
Whoah, whoah, whoah, now wait a sec here. We're talking about a program invented by Linus Torvalds, the creator of a kernel that routinely sits under userlands where a synonym of "feline" prints the contents of files, where a household cleaner (vim) is a text editor, where "more" and "less" do the same thing despite being literal opposites, and where sometimes, but not always, parameter names are case-sensitive (rm -r == rm -R but rm -i != rm -I).
So of course git is hard to learn. Just like Linux itself, it makes you fucking work for it.... but then it pays you back a thousand times over. I'm not going to try to convince you that git is the best source control solution out there, but boy oh boy can you ever do a lot with it once you understand its mental model.
It's not much use until the vast majority of users have adopted these compatible browser versions.
Not being intentionally negative, but how long will this take in reality?
Not long.
caniuse.com says that 67% of browsers currently in use in North America support WebAssembly. The 33% breaks down like this: 10% iOS 9/10, 6% IE, 4% Edge, 3% Samsung browsers, and 10% for every other rickety thing out there.
Give iOS 10 -> 11, Safari 10 -> 11, and Edge 15 -> 16 upgrades another 3 months to roll through (these are all safe and good-quality updates), then WebAssembly availability will be over 80%. That's good enough to take a dependency on. Millions of people keep on using IE, Android Browser and Opera Mini, which aren't getting any updates at all, and nearly 100% of those people have access to another device or browser which does support WebAssembly.
I know a lot of people have already checked out because they didn't like being sold a bill of goods. I totally understand those people. But for the rest of us who just want good games to play and don't care about the release-time controversy, it's looks like there's a better future coming. Hello Games has now added three major elements that were never announced or even hinted at prior to the original release: Land vehicles, base building, and now terraforming. Were these planned all along? Maybe, maybe not, but it's clear that more content and features will continue to be released.
For all we know, NMS will become a continually-evolving game like Eve Online, Elite: Dangerous, or even Starbound.
His Slashdot UID indicates he joined this site significantly earlier than me - and I was here in 2003. Are you suggesting he signed up in utero?
I've been reading Slashdot since late 1998. By March 2000 the signal:noise ratio in the comments was getting pretty intolerable, so I created an account and set my minimum reading level to 3. 17+ years later, that filter keeps on serving its purpose, dutifully hiding comments from people calling me a "millennial" because I had the audacity to stand up for enjoying what I've been paid to do for the last 30 years.
Never change, Slashdot.
The work that software developers do is extremely mentally challenging. We're often under pressure to not only create a product that is good enough to be profitable (or at least helpful), but also to not make extremely subtle mistakes that results in security vulnerabilities, information exposure, or denial of service.
That's why we like putting little jokes in our software. It helps us cope with the pressure. It's why song lyrics, movie quotes and ASCII art find their way into code comments. It's why JIRA's about page is presented as an 8-bit video game. It's why we have an RFC describing an "evil bit". It's why error pages for popular source code repository have anthropomorphic robots. Hell, even MS Excel had a freakin' flight simulator built into it at one point!
The world is bad enough as it is without the misery-mongers demanding we excise all forms of fun from our line of work. Leave us alone. Let us have our fun. We know what we're doing.
How come they didn't go with Mercurial?
Some obvious reasons off the top of my head:
You can also make the argument that Git was designed from the beginning to be suitable for developing an operating system. Or, put more bluntly, it was designed to be used by programmers who are smart enough to work on an operating system, Yes, the Mercurial CLI is generally easier to come to grips with, but that isn't a compelling enough reason on its own.
Keep in mind also that the overall direction of Mercurial is increasingly being driven by the needs of Facebook's dev teams. Which is great to see, in the sense that they're returning their enhancements to the community..... but by and large they're building web properties, not operating systems, so the priorities may be different.
Microsoft are just getting efficient. They have simply skipped "Embrace".
No they didn't. For one thing, Git has been supported in TFS for four years now. And then there's this:
"Among them, we learned the Git server has to be smart. It has to pack the Git files in an optimal fashion so that it doesn’t have to send more to the client than absolutely necessary – think of it as optimizing locality of reference. So we made lots of enhancements to the Team Services/TFS Git server. We also discovered that Git has lots of scenarios where it touches stuff it really doesn’t need to. This never really mattered before because it was all local and used for modestly sized repos so it was fast – but when touching it means downloading it from the server or scanning 6,000,000 files, uh oh. So we’ve been investing heavily in is performance optimizations to Git. Many of them also benefit “normal” repos to some degree but they are critical for mega repos. We’ve been submitting many of these improvements to the Git OSS project and have enjoyed a good working relationship with them."
https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-story/
But if multiple applications in Office share a library, where do you put that library so that the build process for each Office application can see it? Are submodules or subtrees a good choice, and if "yes," which is more appropriate?
Microsoft experimented with the submodules approach for Windows. Didn't work:
"We started down at least 2 failed paths to scale Git. Probably the most extensive one was to use Git submodules to stitch together lots of repos into a single “super” repo. I won’t go into details but after 6 months of working on that we realized it wasn’t going to work – too many edge cases, too much complexity and fragility. We needed a bulletproof solution that would be well supported by almost all Git tooling."
https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-story/
Yeah, Adobe. Just finished dealing with them this morning. And by "finished", I mean finished.
I just set up a Mac with MacOS Sierra 10.12, and attempted to install my copy of Photoshop CS5. Sierra advised me to throw the installer in the trash. Seriously. That's the dialog I got. Adobe "support" told me "not compatible with 10.12", and also "there is no fix or upgrade" other than enter into a permanent wallet-sucking fest for their "subscription" based product. No. Not a chance.
I hear your frustration, but don't lose sight of the fact that this is actually on Apple for failing to ensure their operating system is compatible with some of its most commonly-used products.
Back in the day, the Classic -> 10 and PPC -> Intel transitions were pitched to us as necessary one-time jumps to ensure the future health of the Mac. And we could accept it because we could see that we were talking about fundamentally different operating systems and fundamentally different hardware architectures. There's no justification for Mac OS X 10.6 software not working on macOS 10.12... they aren't fundamentally different. For the most part, it's just some API differences. Apple just doesn't really give a shit about backwards compatibility, simple as that.
Also, it has to be said: Adobe CS5 is known to work on the latest versions of Windows 10 with the exception of Premiere. Microsoft sinks a lot of time and effort into ensuring software that runs on Windows 7 continues to do so under Windows 10.
Can we get something like windows 10.01 10.02?
Or Windows 7 sp2 or SP1.5
Windows 8.2 or 8.1.5?
Sure. It's already there. Just gotta understand how Microsoft versions Windows now.
(TL;DR: Mac OS X 10.11.6 == Windows 10 10.10586.589.)
Microsoft publishes a list of the cumulative fixes for Windows 10 and their Build/UBR numbers on their web site. They've never done this kind of a list for previous versions of Windows.