Please create an account to participate in the Slashdot moderation system


Forgot your password?

Comment General IT (Score 1) 168

A more general IT course would be better as a requirement. It could cover the relationship between clients and servers/clouds, what an OS is and isn't, normalization and data relationships (one-to-many, many-to-many, etc.), pro's and con's of different kinds of data keys/id's, encryption techniques, etc.

They will likely need to know a bit about such in the work-place even if they are not a coder. Coding is only one aspect of IT.

It's better 100% of students are slightly less naive about general IT which at least 90% will use at work, compared to 100% prepared for a career in coding that only 3% will end up in. It's not a logical use of school resources and time to put a coding class over an IT class.

Comment The Incentive Problem (Re:Cultural?) (Score 1) 462

I agree. There's usually very little incentive for engineers to cheat like that.

For one, their paychecks won't very that much between cheating and non-cheating. They'll likely get a paycheck whether the car is profitable/successful or not. People rarely cheat this big unless there is a clear and large benefit to them.

Being fired due to a downturn in sales is always a worry, but in this case there is a roughly comparable risk of being fired by management for cheating.

Engineers risk being caught by both managers AND the public (external people). If top managers cheat, they only have to worry about being caught by the public.

Thus, the engineers have to weigh the incremental possible raise if sales are successful versus the risk of being fired if caught by management. I don't see a clear net benefit here.

Upper management and CEO pay/incentives are usually much more leveraged on the rise or fall of sales and profits.

Unless something really odd is going on, it's not the rank and file engineers who made the final call. It would take more than one engineer to pull it off, and a group of engineers will know that the "incentive math" is not in their favor.

Generally the group of engineers needed to pull it off haven't chosen each other, they are just happenstance co-workers such that it's not comparable to a say self-selected crime gang.

Comment Re:Not quite (Score 1) 208

While not an OEM per say, I have done this with a Windows 7 System Builder version. Install Win7 System Builder, Upgrade to Win10, reinstall Win7. I did not do the rollback: an actual fresh Windows 7 installation which then requires activation. The activation of Windows 7 upon reinstall worked just fine. Granted, System Builder != OEM, but still...

Now, whether I could -for example- replace the HDD in that machine and try to install Windows 10, that I don't know. The hash is indeed for the machine you upgraded with all hardware it had at that point. However, for many machines upgrading is not somethiing that will happen (think laptops). I had planned to try such a situation (upgrade with 4GB RAM, nuke, install 8GB RAM and then install a fresh 10 and see whether it activates), but I have only limited time.

Besides, they're so desperate to see 10 adoption, they'll look a lot though the fingers.

Comment Re:Not quite (Score 1) 208

To be more precise, from what I understand. You upgrade your license (the OEM SLP one or the one on your sticker, which are technically two different licenses. Draw your own conclusion from that and how you can abuse this). During the upgrade process, you get a new product key. This product key, from what I've seen, is the same for every machine that is upgraded. That Win10 product key, for Home, ends with 8HVX7, for Pro, ends with 3V66T. Google that if you want.

What really happens is that a hardware hash is sent to Microsoft during the upgrade process. This hardware hash allows you to use those generic keys in the future (well, depending whether you had Home or Pro... Obviously), which means you can just use the generic ISO Microsoft provides (Finally, an official re-installation ISO! I've been waiting years for that). You can not use those generic keys on non-hashed hardware (Yes, I tried to see what happens). It will not activate.

However, your 7 license will remain fully functional. At least, that's my experience.

What would be an interesting test would be the following: Install Windows 7 in a VM, clone it, but don't run the second instance. Start the first instance, upgrade to 10. Keep it on 10. Now launch the second instance, which is 7 and never upgrade it. See if both remain active. This definitely violates the Microsoft licenses you have, but it would be interesting to see what happens. My prediction: both stay activated, but I'm not sure. I haven't tested it.

Comment Re:Not quite (Score 1) 208

For all Windows machines I have under my control, I upgraded to secure the upgrade that I'll have to do in 2020 anyway. Then in clicked "go back to Windows 7" (well, actually, I didn't... It's easier to image the disk, do the upgrade, and restore from image).
I did this for all machines I have with an OEM license. For some machines, that run Linux, I even bothered to image Linux, install the OEM that came with it, upgrade, put back the Linux image. Why? Because, those machines might still be functional in 2020. It might not be me who will use it, and the future user might prefer 10, so I like to give the future user that option.

That is quite a lot of work, well mostly quite a lot of time, but that way I have the license, and I can continue to use whatever I like (7 or Linux), while keeping my options in the future open.

No line available at 300 baud.