Not the OP you responded too, but what the hell! I have not really used windows in a while but that's absurd. That text is massive just for an unsigned driver.
I think somewhat sand boxed is fine, but the user should at the end of the day be allowed to let things out or get out if it.
The problem with things like iOS is the user can't make that choice. Also what you call 'bad' is up to the user. At the end of the day a user should be able to adjust things even at root level or request other software to do that on their behalf. Heck for iDevices owners should be able to load their own signing keys at a minimum for the Boot-ROM.
As for Adobe most people would not expect their software to touch the host file, so it's fine to call them out here. Someone using a utility or tool that you would expect to edit the host file that's fine, and people should be able to use or make such a tool. (The os should not prevent the user/owner if that's what they want).
Yea, that's what I was getting at. The user should be king. Not the application developer, not the OS vendor. The user should be able to easily say yes/no to these things and have the final say.
Yes, I did actually look at Bunki as well before building this. Liked the imagery. :)
What did not quite fit for my purpose was having the asymmetric coroutines as the fundamental layer, meaning that the dispatcher also is tied to that layer. Building the next level dispatcher on top of that is probably possible, but seemed a bit complicated.
I instead started with symmetric coroutines as the fundamental building block and built the dispatcher at the next (process) layer where it can deal with the event queue to determine who goes next. The process level resume() call is always made from some event executed by the dispatcher on the main stack, making the processes asymmetric coroutines even if the lowest level coroutines are symmetric with transfer() calls.
Making asymmetric coroutines from symmetric ones is easy, just yield(void) { transfer(parent); } and resume(target) { transfer(target); } in slightly abbreviated code, while going the other way around requires an extra context switch via the dispatcher on the way there.
If your worried about acrylamides then you should not be browning any starchy foods. A lot cooking intentionally wants the Maillard reaction for flavor and texture reasons.
When it comes to seasoning carbon steel you should not be letting carbon build up. It's a bad habit. If your getting carbon build up clean it off with something coarse like salt or a metal scrubber. After that if you need to it's not hard to give a pan a quick touch up seasoning with oil. Carbon steel is much quick to touch up season than something like cast iron. Cast irons rough sand cast surface means you generally need a much much thicker seasoning layer.
You also should still clean the pan too! Modern dish washing detergents are generally not made from lye so won't strip your seasoning.
Wish I'd thought of that; I spent a couple hours at it using an orbital sander, up to 320 grit. No regrets though, that pan is easily my favorite piece of cook ware.
Acrylimides do not apear to be likely to acumulate on iron cookware, and types that may be formed in food, are not concidered probimatic.
https://en.wikipedia.org/wiki/Acrylamides
Even with that link I have trouble believing it myself.
Like how was this data/survey gathered/administrated? Sample size ect...
Also I don't understand how sports seem to get so much attention. Like they are just games why?
Another post I was reading a bit ago was how Spain what basically suffering internet outages to stop pirate streams of games on the weekend: https://news.ycombinator.com/item?id=45323856
Like why is a game considered so important that even internet traffic has to suffer. It boggles my mind.
> Like why is a game considered so important that even internet traffic has to suffer. It boggles my mind.
Because that game makes 1.8 billion dollars a year in TV licensing rights [1], and pirates undercut the pay-TV stations' ability to recoup these expenses.
Add in a ... questionable legal system, club and league presidents with friends with very very deep pockets, cloud providers that don't care what they host as long as the legal system of their host country absolves them of liabilities and that's how you get inane rulings like this.
I would say part of it is that ARM never really had wide spread socketed chips. It's pretty much just always a soldered highly integrated unit.
Go go back far enough you had a point in time for example you could swap an Intel or AMD cpu onto the same motherboard. Also using expansion cards for additional hardware capability was the norm. So software kinda evolved to handle disparate configurations of hardware.
ARM evolved differently. It end up being to be used more in embeded and then SoC systems. Hardware around the CPU and later on Die ended up with often a unique configure for the system/device. So the need to handle disparate hardware configurations was less important. Also the way ARM licenses their IP definitely pushed things to be more like this.
RISC-V atm is often being used in place of ARM so a lot entities are kinda are treating similar to ARM when developing a system/device. However, RISC-V since it's an open license on the ISA does not have to be used in similar way. Like imagine if there was some standardized socket for RISC-V chips and that took off, we would probably see things like UEFI and drivers/kernel drivers meant to work with more than just one single configuration of hardware ect...
reply