Think of something like Linux. When you boot it up, it prints a banner, which contains the version and timestamp and who built the kernel. (Linux 6.7.1 built on date by blah). That's a timestamp - it's handy during development because hey, the version number might stay the same, but the timestamp gives you a rough idea of where to look at what changes it might have. But they're murder on reproducible builds.

Another one is if you're doing parallel builds - the build server may have 20+ cores on it to make builds speedy so you build Linux using all 20 cores. But which cores get which source files is completely random and if you have an Intel performance and efficiency core thing going, the E cores would take longer, and this can affect the link order of the kernel objects. Changing the link order may mean objects are laid out differently in the final binary as well as branch and jump addresses. Especially tricky since the kernel partially links every file first.

The fun one to get is filesystem layouts. When you traverse a directory, you often get files in the order the files were created in the directory. If your build system does parallel builds, the order the files are created may no longer be deterministic because as the code is built, it's placed int he output directories randomly. When the filesystem image is built, it's often done by pointing the tool at a directory, so the tool enters the directory and then traverses it creating the image as it encounters files and directories. If the build system puts files and directories in a non-deterministic order you can often get files added randomly which can mess up the image. COmpression and encryption compound the problem. (Most tools use calls like opendir() and readdir() to get through the directory tree so the file order they add to the final image is dependent on the order they were created in the directory). This is the hardest to solve, but it can be done if the tool sorts the files first in alphabetical order before processing, thus ensuring files are processed in a deterministic order.

The biggest non-determinism is that, usually. But especially since it can be caused by parallel builds so even if you start with exactly the same files, the final arrangement can vary. If you're unpacking 20 tarballs in parallel it just creates chaos.

Of course, the easiest way is to make it deterministic and only allow one build to proceed at a time, but that means what takes 20 minutes to builds completely now takes hours. And even then you might get some randomization because the disk cache might cause a file to be written ahead of another

And the problem is that women often don't know they can enter these fields.

There are tons of women who want to enter trades. However, all they see are men everywhere - and thus society has set up a stigma that "girls can't code" or "girls can't be electricians".

The assumption is "girls aren't interested" is about as true as saying "boys don't cry". It's a sexism thing - girls play with Barbie, boys play with GI Joe. Heaven forbid you have a boy who's interested in Barbie, or a girl who wants Transformers.

In fact, many trades have "girls do trades" type events where the whole purpose is to show that yes, if you want to sling a hammer, or do electrical work, or plumbing, or whatever, you can. Often there's no role model to say "yes, you can!" in a family context, so plenty of people make the assumption that no, you might like to work on the computer and have a great time at it, but only boys code, so go and be a nurse instead".

I'm sure there's probably a huge dichotomy of people who are in unhappy careers because it "fit the stereotype" rather than actually exploring options in what they are more interested in. I know people who did computer science in university because they didn't know what to do, so their parents said to do computer science as it was popular. I'm sure you all know how that usually turns out

And the reason I think it's cultural? Other cultures have often no such qualms. I've seen lots of women from Indian, Chinese, or Eastern European backgrounds. They were encouraged to do the sciences and they pursued them Also, take a look at advertising for video games prior to the videogame crash - you'll find it's often done as a family activity with both a son and a daughter enjoying what little game there is. But afterwards, it's purely something the boys do. And it has something to do with Nintendo - because in order to sell the NES, Nintendo couldn't market it as a "video game" as that was poison. So they marketed it as a toy (aided by Robby). But if you do that, you need to pick - does it go in the boys section or the girls - heaven forbid a toy might actually be interesting to both sexes.

All I can say is that the race to the bottom to cut salaries on IT workers can't end in anything good.

You just have to look at other industries. You know, like say, manufacturing. Most things are made outside the US, because it's cheaper to make stuff there because pay is lower.

The same forces that pushed manufacturing overseas is the same forces pushing IT salaries lower.

>"Also there the issue of let's say I want to port my giant CAD app to Linux? Which distro? Which installer package? There's a lot of variables with that."

Yes, but it is not that difficult to overcome. Porting/coding it is mostly a single investment/code base and will essentially work on any Linux. The packaging of it is easy, in comparison. You just have to follow some reasonable practices of using conservatively-available libraries, or include your own. Probably target a generic deb and rpm for the major distros, and also flatpak. I have used numerous commercial Linux packages for decades and they figured it out :)

Porting is fairly easy. You port to the Linux most people will use.

If it's a CAD program and you expect people to use it in a corporate environment, you go RHEL and be done with it. Hell, the company is probably already paying thousands of dollars for support anyways (aka subscription) so using a commercial Linux isn't really too unusual.

If you were a little lower end and your package is used by people ancillary to the job, then you might target a more mainstream Linux, like Ubuntu. And let what3ever that uses be what you support.

That's all you really have to support. Everyone else using something different can figure it out for themselves. Linux Mint, Arch Linux, Debian, etc., those users are experienced in Linux so let them figure out how to get it working.

Heck, if your application is that damn important, people will find a way. If it means having to have a whole new computer just for your application, so be it. Computers are cheap these days.

I've only tried the original Half-Life trilogy so far, but Steam on Linux seems to work well for at least some games.

Steam has Proton, which because of the Steam Deck, it has significantly improved gaming on Linux. About the only things it doesn't work on are games that require kernel anti-cheat.

And while Proton only works with Steam (though its changes are pushed back into WINE), you can still run other stores using it since you can add any app you want and run it under Proton.

I've long held that the use of biometrics to replace passwords is a mistake. The classic "username" and "password" combo provides two pieces of information in order to verify identify: who you are, and something you know. A thumbprint, or an iris scan, more accurately represents who you are than something you know; so using those to replace your username would make sense... but using them to replace your password seems like a bad idea.

Except that the truth is far worse. The reason phones use biometrics is because without it, people were not using anything.

Remember "slide to unlock"? Have you remembered seeing anyone with that on their phone? Circa 2012 or so, studies conducted showed only about 20% of phone users had a PIN on their phone - the rest of them used the default password less slide to unlock.

The reason for this was simple - people were checking phones, and the added annoyance of having to unlock your phone was a deterrent - people check their phones hundreds to thousands of times a day, and unlocking every time turned out to be not worth the effort.

That's why they added biometrics - because now people would be forced to put a password on their phone, but it wouldn't be annoying since they would put their finger on the sensor and it would unlock for them by the time they got it into view.

So yes, password is best. however, it was interfering with the need for people to quickly glance at their phones. Biometrics solved that because now users would generally not be bothered with a password entry dialog most of the time so they could continue to use their phones with a password because it's not getting in the way, most of the time.

Phones still allow you to disable biometrics so you can have password only authentication. However you'll probably find people disabling it after a few hours of inconvenience.

And that's why all phones nowadays have SOS modes, so you can disable biometrics until the password is entered. Just lear the key combination (it's usually a mix of power button and volume button) and the biometrics will be disabled until the next successful login.

how does an six- to nine-month school cost 30K?
now an full collage can cost more and the loans are harder to get out of.

Private schools often cost that much or more. It's why Catholic private schools are an extremely popular option because their costs are usually 1/10th of what a normal private school costs.

No. The "ruling" was that there is no human creativity in AI-generated material, thus nothing subject to copyright.

You also appear to need reference to the sweat of the brow doctrine and its inapplicability in modern copyright law.

It's the phone book or recipe book copyright. The contents of the book (the phone numbers, the recipes, etc) are not copyrightable. However, how those phone numbers and recipes are laid out, that can have copyright.

But you're just as free to take those recipes and put it on your website as long as you don't reproduce the layout or other copyrighted content (e.g., photos).

So if the book gets published, you're free to re-type the text of the book out and give it away for free because it's in the public domain. However, if there is artwork and how you format the pages is copyrighted, So make sure you use a different font.

You're also free to make adaptations of the content - an audiobook, for example. You can't copyright the content, but the recording of it is copyrightable

Honor among thieves is a myth. It would be funny if they did release it, not only as an outing, but a way of making a lot of personal enemies, that have no ethics in solving a particular problem.

The quote is "There is no honor among thieves". It never existed in the first place. Because if crooks can't be trusted (they're a crook, they already did the crime), why would a crook trust a crook?

I mean, they're willing to break rules to get what t hey want, so why would they suddenly be willing to obey a rule in a slightly different context?

That said, you do occasionally see it where one criminal doesn't give up the name of their co-conspirators for some reason or another. Which is generally unusual since while they get to rot in jail for the crime, it's likely their partners don't even care about that - they're living it up. So you really aren't getting anything by not squealing either - other than the honor of being forgotten about.

Basically a big miscalculation of what people would do. I guess they expected a good chunk of people to have been stuck and continue to pay, and they made such changes so quickly everyone decided to ditch rather than stay.

It's the problem - they went from acquiring to making changes way too quickly and people generally get very scared at that. The speed of which basically started everyone into looking at alternatives.

And alternatives exist - ProxMox even gained the ability to import ESXi machines.

The problem was they started making changes so quickly people got scared. Chances are if they sat around on the licensing front and let things settle they'd probably get less churn,

But nope, they decided to rip the carpet from under their users - one day licensing is this, the next day, it's that, and that's done. No time to sunset old agreements, just switch over with no announcement and no transition or migration plan.

Even Google, known for killing their stuff, generally gives at least a month's heads up that stuff will end, sometimes way more to allow users to migrate.

Particularly with firmware, you get chunks to cover bits and pieces but you have to provide certain bits and pieces. I'm frankly shocked how bad the 'ready to go' firmware even from someone like Insyde or AMI is, who you would *think* would have it pretty well down by now. You can have the most milquetoast combination of predictable components and *still* need to do work to behave as well as a Dell or Lenovo even if the components are largely the same, as they have some on staff firmware developers that build on top of the vendors and they don't share their assets with the world. Hell, it's obvious that they don't even share with themselves, some product families are worlds apart from the exact same company with the same chipsets.

A PC has a lot of custom components on it and that's where a lot of the BIOS work comes from.

For example, most PCs need a programmable clock generator to generate the various clock frequencies needed by the CPU, chipset, memory, slots, etc. Did you know there are hundreds of chips out there that can do this? Well, the motherboard manufacturer gets to pick one (and likely a bunch of alternates because supply chain) and put them o the board. But now your BIOS needs to support that chip, so someone needs to write code to support that chip.

But also, there are infinite number of ways to hook that chip up to the various components - many have multiple channels so channel A may go to the CPU, channel B to the RAM, etc., or someone else might do it another way, with Channel A going to RAM, channel B to the chipset, etc.

Likewise, PCIe has two methods of signalling interrupts - an interrupt pin or an interrupt message. Interrupt pins need routing to the interrupt controller, and how that's done is different on every board. Likewise, the interrupt messages are used to have the root complex signal an interrupt on usually another interrupt line.

Then you have the dozens of other controllers - most motherboards have RGB support, which can come in at least 3 different flavors.

There's probably dozens of GPIO lines as well, used to do various things - like vritually set jumpers, write protect the flash chips, and other features.

All those things are something BIOS vendors need to support.

Then there are the fun ones like the ACPI tables (or programs, since it's really a VM like thing). Like when you suspend a PC, you need to start suspending memory, then suspend devices, the CPU, etc. And often toggle various IO lines as you shut down components

Oh, and the BIOS is modular - because someone may want features that someone else doesn't want to pay for.

You don't need to run the entire model - Google's model is apparently very RAM hungry as it would need 8GB of RAM.

If you design your device with that in mind, 8GB of RAM to run a model isn't all that much - given it's IOS, Apple will probably only need 4 or 8 GB of RAM for the OS and applications, so your device will only need 12 or 16GB of RAM total. Not really unheard of (12GB was what "flagship" Android phones had years ago).

This is why a signature should still be a requirement for anything to be legally binding. An accidental click won't result in her signature being written on a final approval document.

Except that's what lawyers do. Lawyers are called "your representation" - if you go to court, you can be absent and have your lawyers represent your case to the court. You give them that power when you hire them. You can hire a lawyer to answer questions on law, but usually you hire them to represent you in a lawsuit.

When you do that, the lawyer's actions represent you. If the lawyer misrepresents you by taking a deal you don't like, your recourse is to sue your lawyer for misrepresentation.

It was way more up to the mid 90s or so to have these doodles - basically right when we started going from LSI to VLSI in designs. In LSI and early VLSI and before, chips were generally laid out by hand - hand drawn in mask (you might remember people saying Rubylith, which is a masking film so when it came time to do the photoreduction the rubylith would block light, but under normal light it was a transparent red so you could see what you're masking).

As such, doing such doodles was relatively easy since you had the time and space to do it.

But once going into the VLSI era, on digital chips it started to be whittled down to initials and such. But it was also strongly discouraged because those doodles had been known to interact with signals causing issues.

Because analog IC design generally doesn't use VLSI techniques, they often still have doodles because a lot of it is still manually laid out by hand. (Analog IC design isn't using cutting edge processes).

These days, you're really likely to just get initials as it's relatively easy to get those imported into the design and there's generally an area of the chip for such text anyways (you usually will have die ID codes visible).

Nope. Apple still requires ALL apps to be reviewed and notarized.

I'm not sure why people keep having this misconception that Apple has opened anything up. Apple still has final say on approving an app, which means that this is nothing like how it works on Android.

No, Apple is NOT reviewing any apps not using the App Store. Apple is notarizing apps, but that just means Apple is signing them.

Basically you send your IPA through Apple's page, and it comes back to you signed.

Apple will sign anything, without reviewing it. If something turns out to be malware then Apple could potentially figure out whose app it is and ask the developer to fix it.