|
And to think, they want to us blindly install updates immediately now. Trust the corporations without question. Big tech knows best. We're just plebes.
As a side-ish note, even VS Code is getting odd. I swear every other day I open it up there's a new update it's bugging me to install. Fortunately, it doesn't crash or anything, but here I thought I was supposed to use it to actually do some work.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: thought I was supposed to use it to actually do some work. Work? I thought you were a manager.
|
|
|
|
|
I went back to doing contract work. One of the things I love about the business side is being able to make an impact, rather than having a boss "above" you that's too afraid to be honest with the business. But, it also consists of a bunch of useless meetings that waste people's time with folks that have no earthly idea about tech and are usually in it for the wrong reasons. I intrinsically lack respect for people who only wish to tell others what to do rather than do actual work themselves. I mean, there is value in the business side of course, but most of it is fluff and garbage.
Ok, I'll stop ranting now.
Jeremy Falcon
|
|
|
|
|
I agree 100%. I worked for too many bosses for whom I had very little respect.
|
|
|
|
|
So did I, on the other hand, I did manage to be respected by them.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
"I swear every other day I open it up there's a new update it's bugging me to install."
Looks like you don't have a Linux box.
|
|
|
|
|
Peter Adam wrote: Looks like you don't have a Linux box. Frequent updates are actually worse in Linux because every day you log in, everything is updating daily. Even with distros such as Debian.
Jeremy Falcon
|
|
|
|
|
My very latest Win11 and VS update left me with a '.NET' error and my VS-generated VB.NET app refuses to run! Starting the VB.NET app in Debug-mode in VS generates the same error message.
What's going on here?
|
|
|
|
|
Didn't take so much for me. Was over in max 10 minutes.
Note: Is it geography dependent? I live in India.
|
|
|
|
|
switch to linux lol....
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
abmv wrote: switch to linux lol....
Yeah, 'cuz Linux never gets borked updates, no matter what odd combination of packages you might have, all coming from a bunch of devs that have nothing to do with each other.
|
|
|
|
|
I've had way more issues with Windows than I've had with Linux. The first couple years of Windows 10 was fairly bad for me. I've got 10+ machines running Windows and there'd be 2 or three that couldn't do the latest feature updates. Tried all the 'fixes' I could find on the web to no avail. Had to do a fresh install on the affected machines. And it wasn't always the same machines that would get borked on the next feature update. This went on for about 2 years.
With my Linux updates, I've had one issue in the last 3 years. My email client (Thunderbird) wouldn't run after an update. Did a little research on the web and figured it was related to AppArmor preventing it from executing. Told AppArmor to ignore Thunderbird and then Thunderbird worked normally.
|
|
|
|
|
Cool story bro.
Thing is, everybody has a different one. I'm glad it's working out for you.
For me, if I were to just call it as I see it, my observations could be summarized as "different OS, different problems". And that's the only point I was trying to get across.
|
|
|
|
|
Cp-Coder wrote: This update robbed me of more than an hour out of my day!
I usually leave those updates for the end of the day.
Unfortunately with a very wide hardware base no company could ever hope to test all combinations. Add into that the potential for existing problems with that hardware and it becomes an unsurmountable problem.
The alternatives are no updates or to just wing it and see what happens. The latter is that for many systems it will work.
|
|
|
|
|
Things were a lot better when MS had their internal testing lab. now the updates are released after dogfooding on their own VM's, not actual hardware. Things have been really bad for patches ever since.
|
|
|
|
|
Dave Kreskowiak wrote: now the updates are released after dogfooding on their own VM's, not actual hardware.
That's been my argument as well...maybe their updates are well-tested on VMs, but virtualized hardware (and their well-known drivers) is NOT representative what most people are actually using, and then encounter problems that MS hasn't seen doesn't bother trying to seek out.
For a multi-trillion dollar company, they can do better.
|
|
|
|
|
You misunderstand. They are tested on the developers VM's. At one point, the old testing lab moved from actual hardware to a bunch of VM's before the entire lab was just shutdown and everyone laid off when Satya took over.
|
|
|
|
|
Same difference, updates are only tested on VMs, not real hardware. Whether it's being done by devs or a dedicated QA department really doesn't make much of a difference at that point - a lot of bugs are simply gonna be missed.
|
|
|
|
|
dandy72 wrote: a lot of bugs are simply gonna be missed.
Versus when?
Windows 98 had 13 million lines of code.
Windows 10 has 50 million.
So certainly then one should expect at least 5 times as many.
And how many variations of hardware are there now?
How many variations of software are there now?
As an example Windows 98 was released in 1998. In 1999 99% of computers using the Web were using Internet Explorer. Keeping in mind of course there were quite a few less features then in any browser. But quite a bit less to test to insure it ran on Windows 98. And it was considered part of the OS.
|
|
|
|
|
jschell wrote: Versus when?
A lot of bugs are simply gonna be missed when testing only on VMs versus when instead testing on the infinite "variations of hardware" that exists, as you put it.
They can't cover it all, but they could at least try some subset. Not just VMs.
That's all I was saying; I'm not sure where you were going with your line count comparison. If any comparison's to be made, it should at least be between two versions of the same product line (9x vs NT kernels have rather little to do with each other).
|
|
|
|
|
dandy72 wrote: I'm not sure where you were going with your line count comparison.
I started off my post with a statement that made it clear.
"Versus when?"
Your post seems to be comparing now to some other time. And I was asking that.
Then I gave a comparison of different time periods that demonstrate the complexity of now versus then. You can provide a different time period if you wish.
|
|
|
|
|
I wasn't focusing on code complexity. I was focusing on the fact that MS only tests on VMs nowadays, and that's not sufficient as it's not representative of the real-world computers actual people use.
|
|
|
|
|
Except there is no way that Microsoft can test in any reasonable way using actual hardware.
Any combination chosen is going to be a very, very small subset of what is out there.
Not to mention that the introduction of the management software onto the machine which would allow them to automate the process would itself change the nature of the test environment and thus guarantee that no machine would match it.
|
|
|
|
|
I agree, it's unrealistic to expect them to have every combination and permutation of hardware imaginable on hand.
But they used to have a pretty good subset of the most popular hardware, and that's reasonable. But at some point they just gave up on even that, and that's pretty much inexcusable for a company of their size/worth. "Works on VMs" is as lazy as "works on the dev's machine".
|
|
|
|
|
That explains why I've had unalloyed success with Windows 10 - I run it on a virtual machine on a Linux host.
|
|
|
|