Posts by doublelayer 11428 publicly visible posts • joined 22 Feb 2018
So your answer to what better thing that USB replaced is...USB? I don't think they were talking about the port shape, and nothing about USB limits how many of them the laptop manufacturers put on their devices. That's a separate issue which doesn't depend on what ports they've provided not enough of.
For updates, it's not exactly a new concept. It's not often done on computers nowadays, but mostly that's due to the long period where disk space was at a premium and reserving lots of it for the image you're not using wasn't considered worth it. For instance, when people did an in-place update from Windows 7 or 8 to 10, the process included moving all the old Windows files, installing the new ones, and if you didn't like the update, you could revert by moving the old files back. In the meantime, many gigabytes of disk space would be used, and I remember some unhappy people talking about that.
However, from your other suggestion: "Antivirus should also embrace this, because as soon one of the roots gets screwed (some honeypot techniques), it should raise an exception and get the virus/malware on the act." That is less likely to work out well. There are only so many techniques that can be used that reliably. It could easily turn into a CroudStrike-esque situation where some program gets updated and starts doing something which is incorrectly identified as malware. Using the previous methods, antivirus software would block that program from running and quarantine its files, and someone would have to go tell it to stop doing that. With this behavior, the antivirus program would force the computer to the old disk image, possibly damaging the user's work, rebooting to apply it, and then the program would install the update and start the loop all over again. If the antivirus was less sensitive, then it might only do this after malware tried to elevate, meaning that the old disk to which it is resetting would still have the malware on it anyway.
I agree that this is what should happen. I am less confident than you appear to be that this is what will happen. Partially, this is because the court does not have to reverse any precedents to confirm the CBP's exception to warrants, an exception that would appear illegal to me. It is also because today's court is quite different from the 2014 court that ruled in the Riley case. There are three judges now that weren't there before, the political situation is very different, and those judges and others have proven more willing to overturn precedents when they disagree with them.
In particular, the US has become more hostile to migrants, and it would be easy for CBP to be seen as a migrant-specific enforcement body even though it is not. A ruling indicating that noncitizens are not protected during entry would not surprise me. Unfortunately, neither would a more expansive version including citizens and extending the situations where it applies. I do not believe that judgement is legally correct, but I am less confident that this is the basis on which it will be decided.
Their previous decision, as explained in the article, did not consider the border police. This judge has extended it to include them. Since other courts have permitted their warrantless searches in the past, they can easily argue, if they want, that they are merely upholding the previous status quo where being near a border or in an airport invalidates those rights. They've done that before. That is not the same as reversing their other rulings. Whether that argument has any legal validity doesn't matter. If they prefer it, they do not have to reverse anything to uphold it, and in fact supporting this ruling will result in more changes as CBP authority in other locations would be ruled illegal.
This is the problem when you assume that what you don't need is also unnecessary for everyone else.
"Self driving cars are a particularly good example. We don't really need self driving cars."
Let's see your arguments:
"For occassions when we don't want to drive, there's taxis."
Unless you're traveling in a way that taxis don't want to. For instance, a long distance that isn't already covered by public transportation. Taxis work in cities, not so well in suburbs, and may not be available at all in rural places. From your comment, I'm guessing you've got access to taxis at convenient prices and wait times, but not everyone does.
"The "work whilst your travel" argument has been lost, because if you can work in the car on the way to the office one can also never leave home in the first place and acocmplish the same thing."
Unless, that is, you might have to travel somewhere and still want to work. You don't have to work while commuting to an office, but what if you have to drive out to a variety of locations during the day and could work while doing that? Or what if you want to travel to somewhere else and to do something, work or leisure, while you're doing that? I'm guessing from your comment that you mostly drive to commute or used to do so, but that doesn't apply to everyone.
The many other purposes of automatic driving weren't considered. There are many companies that want to have those for automated cargo delivery. The human drivers don't like this idea, but the people paying for deliveries would like it if it can be done more cheaply. People who cannot drive may like the idea because it gives them independence in transportation that they now lack. People who like to go on road trips may appreciate doing something else while still using their preferred mode of transportation. Families with only one car may appreciate the ability to send the vehicle unattended to pick someone up rather than having to do that work manually. From your comment, I'm guessing that none of these situations apply to you.
Be careful when you say that something is a pointless waste of time that nobody needs. Sometimes, people have different circumstances to you which is why someone is spending money trying to solve their problem. If all the things I don't like and would never buy did not exist, your life would likely be less pleasant than it is, because it is quite likely that some of those things are things you use frequently.
To be fair, there are lots of things where calculating the ROI is impractical and sometimes dangerous. For example, calculate the ROI on a new backup system. They can be very expensive, especially if you have a good one, meaning a system that hooks into everything that needs to be backed up, has lots of data capacity, has many tiers of storage accessibility and security, and has been developed thoroughly by the staff so that there's no running around when a backup needs to be restored because they've already developed the restore processes and tested them. Now the finance department wants to see the report on how much we've got for all that time and money.
The answer: either something really bad happened in the meantime and you have a good number to tell them after analyzing all their reports on the event to get the numbers, or it's really simple because the return thus far has been zero, if not negative counting the running costs. However, not having it is still worse than having it, and excessive zeal to calculate a return can cause more problems than it solves.
That doesn't mean that AI is something to spend any money on, but just because it's difficult or impractical to calculate the ROI on something isn't enough to disqualify it. Whether it makes any sense as a business model might be a better reason.
Admittedly, those filter boxes rarely work unless this is one manufacturer's set of products, and sometimes not even then. Many sites either lack the filters that we care about or someone fills them in with garbage. I'm thinking of spec lists, lists which go into the filters, which look like this:
Size: 120*58*20mm
Internal memory: included
Memory card: supported
Waterproof: Water resistant design (translation: no)
Material: metal+plastic
However, I don't expect that their bot will be much better at sorting through descriptions or reviews to figure out the real answer. True, if it were a human reading them, it might be more obvious which parts are correct. For instance, for the device above, the disclaimer in the description that indicates that it's not waterproof could be used to cancel out the meaningless stuff in the spec list and they probably have an actual number for internal memory and a specific type of storage card. However, when faced with conflicting information, I am not confident that the bot will figure this out.
Probably a record of a specific contact and payment method, so something that can be used to track them down, but not as convenient as names and addresses of its members. Affiliates that were good at their jobs would probably have good enough opsec that their contact method doesn't identify them and, for those who got payments well before the raids, have probably already extracted their money and hidden again. Those who are not so good could perhaps be identified by law enforcement based on their connection to the organization.
The great thing about it is that you don't actually have to know what it can do. Maybe it will be like India's, where it kills all the mobile internet connections because that's what the average person has, but keeps the wired ones so that businesses can still operate. Maybe it will be like China's where individual sites get blocked and attempts to visit get reported. Maybe it will be like the one China uses in Xinjiang which actually turns off all network traffic (presumably except for government and companies that are working with them). Maybe it will be less effective, as with many DNS-based blocking attempts. You don't need to know which one it is, because the entire point of having any of the above is that, if you're unhappy, this can be used to make sure that your unhappiness wouldn't result in any change.
So that people can find it later on, and so that visitors can actually find things despite the rudimentary and usually nonfunctional search boxes, if the site has one at all. I frequently find something on large, disorganized websites by doing a DDG search with the site: filter. There is one site I've done that with that blocks something needed for that to work, so I can't. Thanks to that decision, they've changed some bot accesses of the text pages to my manually clicking through their blog pages to find the post from seven years ago that I was looking for. Since I was still retrieving the many images in the way because I was using a normal browser, I probably equaled the bandwidth usage for a bot for some time just for that one search.
That comment was not serious, and your response to it, in addition to missing that important fact, is also wrong.
Let's consider a theoretical world where DJI drones are linked in with Huawei-built towers, which to be clear, is not happening. No, uploading video taken during a ten minute flight does not take as much power as flying for ten minutes. Flying around takes lots of power. Transmitting data has nowhere near the power requirements. Also, in our theoretical world, it doesn't have to fly to the tower. It can send to the tower while standing comfortably on the ground, perhaps on the charging station on which the user places it after flight.
In your zeal to disprove something that nobody believes, you've invented several problems with the concept that are not real. The drones are refraining from sending video, but not because it wouldn't be possible. They are refraining from sending the video because A) it would be expensive in time and money to get the infrastructure to transmit it, B) it would be expensive in time and money to get the infrastructure to store it, C) it would be detectable unless they spend even more time and money hiding it, D) if discovered, they'd probably lose customers, and perhaps most importantly E) nobody wants the data that would be collected by so doing anyway. If you can find a way round those five things, I can build you a transmission system that will have few power-related problems.
For most real world programming problems, explaining the whole system is the problem that makes the rest of these unimportant. When I have program design meetings, the two major challenges before us are the following:
1. Getting sufficient description of the parts of the problem that the user understands so we know what we need to do.
2. Making sure that the parts of the problem the user doesn't understand* are sufficiently clear that we can still do what we need to.
* For example, security or efficiency. Even the most detailed of nontechnical program descriptions might say something like "a secure user login system with multifactor authentication". It is our responsibility to provide that and ensure that it is in fact secure. That filling in of gaps is not something the user should be expected to do, but it is still required for the program to work.
Any statement of the problem that is detailed enough to have a mathematical proof of correctness or security could be converted into code automatically. That isn't necessarily proof that it would be adequate for the job. For instance, I'm reminded of some pieces of code that researchers at my university were very proud of because they could be proven correct, but I could write some code in about five minutes that ran a hundred times faster and produced identical results. The proofs would be harder or impossible, but the result for anyone wanting the results in production would favor mine.
I don't care if they make AI-generated images and use them as characters. I do care if they decide they have the right to duplicate people without asking and with no limitation on what they do with them. This doesn't matter whether those people are recognizable, famous, well-paid, or anything else. If they want to do that, they can write a contract that says "We want to record video of you and use it to generate more video of a fake character that will look exactly like you, and that generated video will show you doing anything we want", then ask people how much they have to be paid to agree to it. I don't mind if people do agree to it, and I suspect that you'll find many who don't mind at all. However, don't hide that's what you're doing, don't assume that something else automatically grants you the right to do it, and if you have problems getting people you want to agree to this, consider adding on some extra restrictions.
They don't have to do it that way. They could easily pay actors the same way they pay many other people who do jobs, creative or not. Mine, for instance. I get paid to write some software. They don't pay me each time they run it. We negotiated how much they had to pay to get the software when I was hired. If they do that with an actor, no problem. The reason they don't is usually that they don't have enough money to do that, so they offer to continue paying the actor from money that comes in later instead of paying up front. You could also do software that way: I'll get paid less while writing it, then you give me a portion of the license fees.
Neither has any connection to the AI work. If they buy the software writing from me, they get that piece of software. They don't get other pieces of software I write. They don't even get fixes to that one unless I am still employed. When hiring an actor, you don't get rights to everything about them forever, you get the rights to the performance they just did for you. You want to keep showing that video of them following the script? Great. You want to use their picture in a big machine learning training thing? Get permission to do that or you don't get to.
I don't know how many people this applies to, but there are many who don't know much about Git and use it anyway. When someone first picks up the tool, it looks pretty easy. You add a file, you commit the changes, you push. The code goes up. When someone else has made changes, you pull. Great, I understand Git.
They think that right up until their first merge conflict. Oh, I can't just push while someone else might be doing the same thing. So they learn branches. I push to my branch, you push to your branch, then we merge them. Great, I understand Git.
They think that until they need to get code back. How do I find the code after someone's merged over it? None of my commands do that. So they learn some other ones that work with the history, and they learn some blunt tools for returning to the head. Great, I understand Git.
They think that until a branch merge conflict. Okay, it's time to learn rebase, and rebase isn't a simple command. But they read about it and do some experiments, but now, they know they don't understand Git, at least not fully.
I can't say I do either. I have a relatively good understanding of some of the internals. I know enough to know that you can't simply delete a commit and expect it to become invisible. I can describe some of the internal structures accurately, and I can sound confident when I do it as long as people only ask about the ones I've actually looked at. But since I have not written code inside Git, nor have I memorized every manual page in it, I do not know everything there is to know about Git. Nor am I the least knowledgeable person on my team. We know enough about Git that we get what we need and don't break things. That doesn't make us experts. And we're professional users. There are lots of beginners who know less because they've used it less.
Yes, rotating the key is equivalent to changing the password. You can even leave it public. Anyone on the planet can know that "a83dc027b9a62170" used to unlock something, but it doesn't now. The data is now worthless as long as you can make sure it is no longer usable.
If you can't or don't choose to do that, then deleting the repo looks like a second-best solution. The problem is that it's far too weak and people who think that's good enough are failing a necessary security step. Once it's been committed to the public once, there is a chance that someone has seen it and you can neither reliably detect whether they have nor prevent them from having done so. At that point, you have a risk. Deleting a repo does not eliminate that risk. That credential is compromised and absolutely must be revoked as soon as possible. One of the examples from the article was from a user that wanted to keep using the credential after it had been posted, and that is not a good idea.
"SUN could easily have transformed herself into a Software Business IF they had demanded, from 2003 onwards, moderate license fees for the Java Compiler, the VM, the JRE and so on. Think of 30 Euros per core per year."
Or they could find that people didn't want to and were getting rather tired of being charged. So they stop developing their software in Java, so their customers stop buying JRE licenses. Now they've lost some JDK and JRE licenses. This, in turn, means that the businesses get less value from the licenses they retain, and they start migrating away from Java-based tools. That could happen as well.
It should be rather obvious that it's a possibility if we consider other prices. Had it been €30k per core per year, that would happen almost immediately. Lower the prices and the number of customers you lose decreases and the time between the price change and the loss lengthens. You assume that €30/core/year would be low enough that people wouldn't switch, but Sun's assumptions could easily have been different based on better information about who they would be asking to pay and how much benefit they were already receiving. Pricing is hard, and it can be far too easy to assume that what you would be willing to pay will work for the rest of the market. Oracle is trying this today, but that's no more guarantee that it will work for them.
Sun also had to work around licensing issues meaning they couldn't just apply a unilateral change in terms to every customer overnight. They had to do that because, earlier on, they gave terms that caused people to use the language and they had to. Otherwise, a SaaS business that runs lots of servers and therefore would bear the license increase you describe themselves would have seen Java as too risky a solution and wouldn't use it in the first place. That means fewer developers being paid to learn Sun's language, fewer libraries being made available, which means fewer people choosing to start by learning Java, which means fewer people choosing it in new builds and more people choosing competitors, and all of that means fewer customers for any commercial products Sun did want people to buy. They chose to provide free access, not because they were convinced by an ideological point, but to quickly build up a customer base.
While I can't claim to have counts, I know several pieces of Java code that have been maintenance problems. I'm thinking of a set of three programs from the same source, written in Java without any other languages or dependencies, which ran on Windows, but not Mac OS or Linux. I can blame the developers for that oversight. What I find it harder to blame them for is that you still need Windows 7 or earlier to run them. For some reason, Windows 10 and 11 won't allow them to run. Newer JREs refuse to run them at all. JREs from the same era try to run them, but then crash without usable error messages. These aren't programs from 1998 that happen to still run under Windows 7. They were originally released in 2012 and had updates until 2017.
I don't have the source for these, so patching them is not an option for me. The original authors might have the source and are still in business, but I've given up on them doing anything. Occasionally the idea has come along to reimplement them. If that idea is executed, Java isn't the tool that comes to mind for doing it. I don't think the language is entirely to blame for this course of events, but neither can I pretend that Java is great from a backwards-compatibility perspective.
They had the choice to demand payment for commercial use. If they had done that, they would have gotten some short-term cash, but they might have lost users who didn't want to deal with annoying license audits so they used something else. That limits the ability of Sun to sell other services to those people. As with every other company that has ever existed, they have to decide between these alternatives.
Since this seems to be a big issue in your comments, there's a word for this: capitalism. The company chooses its prices in order to compete with alternatives. Oracle is being no less capitalistic than Sun was. Sun made a decision to get lots of people using Java. Oracle's making a decision to get more money out of those people using Java, taking the risk that people will either use the free alternatives or a different language.
You might also want to stop misstating your facts. Sun had a serious decline. That's a point in your favor. Why make your argument weaker by stating incorrectly that they went bankrupt?
Of course, it's also suggesting that Sun's problems were due primarily to Java, rather than any of their other products that didn't go well, but that's not something you've bothered to mention in your comments.
I could think of things that I would do with one if I had it, but those things are not going to be important enough to justify anything near what the most basic of robots might cost. If I had one, I would likely consider automating some tasks that don't interest me, but it would take a lot of hours freed from such chores to equal the price of the machine and the, admittedly more enjoyable, hours programming it to do those things.
There's also a market problem. If I earn a normal amount of money, which I do, then a robot is likely to be out of my price range in any case. If I'm a very wealthy person, I can try hiring someone to do things that I want done and they're likely to make fewer and less damaging mistakes when starting. I'm not sure the first generations of humanoid robots will have enough demand to sell except to people who like having the latest expensive gadgets, and I don't think that's a big enough market to fund development of the second generation.
I can answer that one. You absolutely need an LLM running in a car when the company that makes the LLM will supply it for $5 billion in up-front "investment", will charge per use, and you own that company. Free money is wonderful. You just add it onto the price of each car, and when people don't buy as many of them, you make some other promise of what other wonderful feature they'll have and wait for people to bid up the stock again. Eventually, this won't work in the long term, but you'll have extracted plenty of actual money in the meantime.
That doesn't necessarily preclude signing. Step 1 makes a file. Somehow, the output was corrupted during or after step 1. The file is then passed to step 2, which signs it. The result is a file that is properly signed, verifies just fine, and once the signed content is extracted, it's still invalid. Steps 1 and 2 don't even have to be separate processes, though they probably are.
"If this were agile, it would be easy to rollback to the previous version."
And from their side, it was. It didn't take them very long to release the version that patched this. The only trouble was that the buggy version damaged things so badly that the users couldn't revert as quickly as the release process could.
It really doesn't matter. They should test their releases, no matter what those releases contain, before going public with them. Whether that is code, or configuration, or some other category of data doesn't really matter. If the behavior of the system has changed slightly, testing is required.
Yes, depending on our definitions, we can argue that it's not code. After all, if someone's counting lines of code from me, they usually wouldn't count the lines of the json file I've just written. But when my program will do something different when the json file is different, it can have the same damaging effects as if I changed what we typically call code, and it therefore needs the same kind of testing.
I'm guessing there was a difference between the version that was tested and the version that got released. That could happen in a lot of ways. Maybe two changes were merged into this file and building them together makes the bad file. Maybe it had to do with some additional content in the production build which isn't present in the debug build. There are plenty more.
I've seen the latter example from time to time. For instance, a task where two people wrote code. First, my coworker wrote one unit, then sent it to me. I wrote the second unit. In my testing, these units worked just fine together. Correct results, no crashes, positive and negative results handled as expected. Build it for production and the automated tests freak out instantly. The reason: my debug build was writing more to the log file in case anything went wrong. That slowed things down slightly, which was enough to prevent the race condition in the two processes from going wrong. Take out the logging and the processes might have a concurrency problem and fail. But it worked just fine on my machine. Probably it would have failed eventually if I ran it with the extra logging enough times, but it didn't in the maybe thirty runs I actually did.
That is calculable. Of course, depending on how you implement it, different numbers and methods would have to be used, but it isn't difficult to get approximate numbers.
For instance, this experiment took place in the US. The current US population is 335 million. We'll also use the same payment amount of this study, $1k per month or $12k per year. This makes a total annual payment of $4.020 trillion. You've asked to have this paid by the top 0.1%, which would be 335,000 people. This makes for an annual payment from them of $12 million if it were divided equally, which it probably wouldn't be. The wealth required to get you into the top 0.1% is $62 million (source). You would need a wealth tax on the order of 20% annually to get that much, and if you did it, it might work for a decade, depending on the return on investment we assume for the funds they retain.
If you try to implement that, expect several consequences, including lots of wealthy people trying to prevent you from doing that. You should also expect that people will search for or create loopholes to get out of it, because you can hire a lot of lawyers and accountants for less than 20% of a 0.1% level wealth. But also remember that it is not going to work forever even if you can get exactly what you asked for. You will need a plan for what you will do after that. Lowering the wealth cap is the most likely solution, but it too won't last very long.
This is definitely true, although some of those jobs didn't disappear but went to other people. But many definitely did disappear. However, we didn't decrease the number of jobs needed altogether; if the people who lost their jobs were not doing any job at all, there would be a shortage of labor. This means that we have not reduced the need for labor, but we have changed what labor we have a need for, and depending on what jobs are available in your area, we may have made the types of labor we want much worse.
This is why I think focusing on the futuristic theory of labor elimination is the wrong approach. Right now, we have people who have or will lose the jobs they have done for a long time. We need to figure out what is right for them right now, not what would be right for them in a theorized world of complete automation, because neither of us lives in that world. If we promise them things that would make sense in that scenario, we will give them false hope. If we require things of them that would make sense in that scenario, we may unfairly burden them for not living in an unattainable future. By considering a speculative future rather than the reality we're in now, we're making things worse for the people who have lost their jobs today.
The reason they're expensive is because of the resources it takes to make them. Not just the metal, motors, and chips, but the labor to manufacture them, the work to design and program them, the expense of maintaining the stocks, workers, and expertise needed to repair them. Because they often need to be customized for each task, a lot of that isn't done at scale, making it more expensive (yes, in money, but also in the sense of how many engineers you hire to do the work or how many different sets of plans you have).
In what sense? There are lots of ways to quantify what ideal employment numbers might be, and there are lots of ways to calculate unemployment. I assume that the "flaw" you're referring to is that the denominator is often the number of people in work or actively looking for work, so it doesn't count those who are not trying to get jobs. Maybe you're instead thinking that the flaw is in data collection which can fail to identify some types of people because they don't appear in employment records. However, neither of those flaws is very relevant to the discussion of whether technology has reached a point where we could continue our current lifestyle with significantly lower amounts of labor or when and what level of technology would be needed to get us there. Even that would probably need a better definition of "significant", which I defined at random as 5% of humans of working age needing to work, but you could easily make an argument that this is too strict a threshold.
When you say "I 'invented' UBI back in the 90s", what do you mean by that? Because you definitely didn't invent the concept. People have been discussing, recommending, and in some cases implementing something like that for centuries. While I'm not sure about the specific term because it's hard to get a search engine to find the first use of it, I also have references to "basic income" and "universal income" from the 1960s, so I don't think you invented the term either.
That's an optimistic picture you have painted, but you're leaving out a lot of things which will probably block you from getting there.
For example, what are the jobs that so many people want to do that they will pay nothing and people will be happy? Remember that many of the jobs that lots of people want now are jobs that pay lots of money; many people don't want to do what a CFO does but plenty of them would be willing to try for the CFO's paycheck. There are some other jobs which are popular enough that you could pay little and still fill them, but those are very limited in supply (often meaning that the people selected end up being paid well anyway).
Now let's consider the jobs that nobody wants. Like, for instance, agricultural work. There are lots of unpleasant jobs there, so the wages for that job would rise significantly. As you said yourself, that means the prices for the products would rise, which in this case is food, which is one of the things the income is supposed to cover. That means the UBI level will have to go up, not down.
The combination of this means that the staples are the most likely to increase in price, and I'm not sure whether anything would decrease, but if it did, it would probably be a luxury good or service. If you don't plan for handling this, the program might fail quickly, which would probably be more risky for future implementation than if it was never tried.
I don't think mass unemployment is going to happen as quickly as the predictions have made out. If we get tech developed even more, it could eventually happen, but we have many tasks that have proven difficult to automate. General-purpose robots that can serve as drop-in replacements for humans basically aren't available, and more customized ones that do one job are quite expensive, so while they're common in things like manufacturing, they're less common when tasks vary too much or are intermittent.
Theorizing about what we should do in that circumstance isn't bad, but it may be premature in the same way that theorizing about how to run a society across solar systems is. It may not happen for many generations, meaning that when our descendants need to answer the questions, our answers won't be very useful to them. Meanwhile, there are lots of intermediate stages which are going to happen during our lifetimes, and if we've spent our effort thinking about the far-out future, we may have planned insufficiently for those.
They could modify the picture on the identification documents instead, but if they did that, the picture would no longer match any other pictures of the victim that might be found online. I wouldn't search out pictures of people to check them against the documents, but if someone did, that might make it difficult to get away with an ID that's just had someone else's picture swapped in. Meanwhile, if they have good enough software that they can appear in a video as the person whose real face is on the ID, then that might be less likely to be caught by the employer before someone is hired. This is especially true for differences in age, because if I change out the picture on an identification document for someone aged 23 and they claim to have ten years professional experience and a birth date in line with that, it might be more obvious that they're not who they say they are.
Maybe the identity they used didn't look much like them, but they didn't have an unlimited supply of fake identities that all look like Koreans of the right age (I think this is mostly young males as North Korea hasn't prioritized computer skills until the last fifteen years and at least one of the technology-focused schools is male only). If they're using stolen US identity documents, they may have to take steps to appear to be the person pictured in them.
There are two really easy ways to get around that.
1. The laptop was delivered to an address in the US. The person at that address has been told to get the package and send it to Hong Kong. The person in Hong Kong has been told to send it to Shenyang. Someone in Shenyang gets it and brings it to wherever they want it.
2. The laptop was sent to an address in the US. There, it was set up with a local internet connection and the IP sent to China or North Korea, where someone set up a remote connection to it.
I've found that "libertarian" usually translates to "those regulations I like and no others". So they'll probably argue here that they don't want people to lose the right to choose whether to accept a non-compete contract, a choice that should come with a compensatory increase in wages. The argument doesn't make a lot of sense in context, but if you find someone and get them to answer, I can pretty much guarantee that's what you'll hear. If you find someone who says they're a libertarian, however, there's a good chance they'll completely disagree with these guys on what is fair and what should be done to make that happen. That's why I don't call myself a libertarian; there are too many people who are using the term who I disagree with and using it would only confuse everything.
I think some version of it, which might not be the same one they're using now, would use cookies set by other Google products as a way to bypass the check. If you identified yourself to Google and they could track you onto the page, then you're allowed through. Otherwise, do a test.
Hmm. What countries might be on the borders of Russia and recently joined NATO? Starts with F. What countries aren't on the border but would be if Russia takes Ukraine? Starts with R. What country has moved closer to NATO membership and is in the latter position? Starts with M.
Maybe, if you went with countries that joined in 2023 rather than ones that joined in 2009, you might have already figured this out.
Yes, they could have implemented a two-stage process where they still have a kernel-level program and it provides data out to something else. There might have been an efficiency drop by doing that, but it would probably be fine enough. The critical point, however, is that this change, while it might have prevented this problem, still involves their being code running at kernel level which, if it broke, would break the kernel. The attempts to blame Microsoft often take the form of explaining that CrowdStrike shouldn't have run anything at kernel level at all, which would not work, and then finding a reason why it's Microsoft's fault that they could, which it isn't.
You mean that one mentioned in the article. It might have read something like this:
"The way that it works is that drivers can set a flag called boot-start," he said.
"So normally, if you've got a driver that's acting kind of buggy and causes a failure like this, Windows can auto resume by simply not loading the driver the next time. But if it is set as boot-start, which is supposed to be reserved for critical drivers, like one for your hard drive, Windows will not eliminate that from the startup sequence and will continue to fail over and over and over and over again, which is what we saw with the CrowdStrike failure."
So they have that by default, and it would have done exactly what you describe except that a flag was set specifically to bypass that safety feature. As it says, there's a good reason to allow something to set itself that way, in case this is required for the system to boot correctly anyway.
Several things in your comment are wrong or misleading:
"The issue here is why a vulnerability tool has to go in the kernel. Something like that should only be running in user space: no ifs or buts."
It goes in the kernel so that it has more visibility and control over what happens. There are some things that can't be done from user space at all, for perfectly good security reasons, and others which can't be done efficiently from there.
Next, the Microsoft is to blame for putting it in. They didn't. CroudStrike is not a Microsoft product or dependency. People install it. Just as if I write a kernel module, I didn't ask for or get Linus's sign-off before running it. People are able to install things at kernel level, and they make the choice whether to do so or not. It is not Microsoft's decision to permit it, and if it was, we would be rightly complaining about the level of authority they claim to have to make that choice for us. They should not and do not deny people the right to do something potentially damaging with their own computers.
This article explains, if you didn't already know, why Windows has to go down when code which is running as part of the kernel breaks this badly. Guess what would happen if a kernel module I loaded into Linux, Mac OS, or any other operating system had a memory violation. That's right, it would panic. It is required to panic. If it did not panic, that kernel has a serious reliability problem.
Until people understand that, the attempts to find a reason why Microsoft is to blame here will not work. Maybe you or someone else can actually find a thing that Microsoft should be doing differently related to this, but while people continue to post comments trying to blame it for doing something both standard and necessary, you will fail to make any case because it appears that you have a gap in important systems knowledge.
I don't agree. Whenever I've seen someone try that, they take a relatively basic approach, one which I don't think gets anywhere. Basically, they follow this plan:
1. Read something the killer wrote. If it's a manifesto, that. If it's not a manifesto, something they posted to social media. If they didn't post on social media, a message sent to someone picked at random.
2. Decide on some opinion that they seem to hold strongly. If this is an opinion you dislike, go to 3. If not, go to 4.
3. Breathless announcement: people who think [opinion] are killers. We should do something about that kind of person.
4. Is there another opinion, one you dislike this time? If so, go to 3. Otherwise, go to 5.
5. Wait for next killer.
Opinions that you can actually make that case about are pretty obvious, because such things often take the form of "I dislike [x] and would like to kill people who, in my mind at least, represent [x]". You don't need much to figure out that a person who says that is potentially murderous. Even then, you have a lot of people who may say that and never actually do anything. If you get any broader, your correlations will be worthless and lead to harmful stereotypes, for instance "The guy who killed people was a soldier, it is not the first time a soldier was responsible for a mass killing of innocent people, that means soldiers are killers". Simplistic to the point of inaccuracy and not something you can do anything about.
I'm sometimes curious to understand the motivations of crazy people to commit murders, but let's call that what it is, curiosity. If we knew that, what would be different at all? Nothing. The victims would be no less dead. Future victims of other people would be no more safe. Maybe, if this was an organized event with other participants, some of them might have been tracked down, but that's not really what you were talking about. Whatever the logic was, we already know that it wouldn't actually make sense to anybody, and unless someone has a stereotype they want to uphold, it would not apply in the same way to anybody else.
That makes it hard to argue for the release of manifestos or the like from murderers when we have them, and it makes it really hard to justify going to the effort to try to break in in the thought that one might exist or be reconstituted from other data. Basically, calls to do so sound to me like "Let's go to significant effort and expense to guess the content of something that might not exist and wouldn't be useful even if we got it".
This seems like a really bad method to get people into the office, even if we assume that we want the goal. For a moment, skip whether getting people into the office is a good thing and just assume that you're in management and for some good reason, you want the people there and you're going to get it. The workers probably don't have a contract that states they can work remotely for as long as they want, meaning that management can, by fiat, just tell them that they have to be in the office. This might not apply to certain groups, for instance if they hired remotely during the pandemic and hired some people in a place where they don't have offices, but anyone who was in an office before the pandemic or could get to one now probably would be subject to such an order. Anyone who refuses can be penalized for not doing what they were told to, up to and including firings. If the company doesn't want to fire them, they can also use a number of smaller sticks against them. Why, when all those levers are available, would they pursue something complicated and potentially illegal with the leave policy?
Often, it is considered the OS's job to execute the software provided, and if you've chosen to let that software run at kernel level because you want it to have access to everything, that means it can mess up the kernel. An operating system that allows you to install software at that level is not compatible with one that can prevent errors executed at that level from having deleterious effects.
So we move on to your next suggestion, which is more plausible, of automatic recovery. That one can work. Have a versioned filesystem, and whenever you have a kernel panic, rewind to an older version and boot that. Of course, if the panic happened because some hardware failure triggered a kernel bug, then you'll end up rewinding yourself to the earliest version available as it panics every time, and it might provide a method for an attacker to remove recent updates in order to reactivate a vulnerability, but in principle the idea would work and those additional dangers could be mitigated by other protections. We would have to figure out what those protections should be and design them, but your second suggestion is possible.
And all you have to do is get it to run at kernel-level permissions. If you have the kind of access needed to install this file to break a computer, you don't need it. If you have that access, you could obtain a similar, if not more severe, action just by deleting files at random until you are no longer able to delete files. That computer is not booting without a reinstall. No booting to recovery and deleting a file will fix it. The benefit to the hacking community, any section, is zero.
Basically, no. If I put in a program which works at kernel level, configure that program to start early in the boot process, and then do something in that process which takes down the kernel, having a Linux kernel instead of an NT kernel won't prevent that from crashing the system nor from making the recovery process annoying. There are some differences meaning that I might not have to run at kernel level for the same purposes, and then maybe my mistake will happen at a higher level and the boot will complete, but there is no guarantee that this will happen. Linux gives the user the ability to run software with very elevated permissions, enough to cause serious faults if that software is badly written.
