Posts by doublelayer 10496 publicly visible posts • joined 22 Feb 2018
Phone calls are not end-to-end encrypted and have never been. There are encrypted voice services available which can work over mobile data. Someone with tower-level access can record call content. I don't know whether they have, though it seems likely that they might have, but they can.
I'm not sure there's much of a choice. They can wait a week, and if they're moving it from Azure's in NL to AWS in NL, they've got plenty of network capacity there and can probably transfer faster than that.
There is a hardware option, with Microsoft having a method to order big boxes with 525 TB of storage capacity. They could order sixteen of those. The problem is that, once those arrive, you still have to transfer it into something else and each of those boxes theoretically maxes out at 120 Gb/s bandwidth if you use three different cables and have something that can handle the other side, but Microsoft estimates that the 100 GbE link will have about 60 Gbps in practice. Theoretically, that does mean you can have 1920 Gbps transfer speed by parallelizing that, but that's going to use quite a lot of cables and upload capacity, and I've only looked at getting the data out of Azure, not what is involved to get it from those boxes into AWS. Once you add getting the boxes shipped to the datacenter where the data is, copying data onto those boxes, shipping them to where you can receive them, shipping those to where AWS will take them, copying the data into AWS, and any more administrative overhead required to get that much hardware in the right places, that speed difference might not be so noticeable.
Not correct. This thread was originally a comparison between this thing and a refurbished Thinkpad. Such comparisons are frequent, and I should note that I was not the person suggesting it. I'm not going to buy either, but the number of Pis I have around here would indicate I'm not so negative on them as DrewPH was. You could have ignored this, but you chose to respond, accepting that a comparison like that could be made, but using invalid methods to do so.
You tell me, and presumably the person who thinks a refurbished Thinkpad is better, to mind our own businesses while participating on a public comment board. You have the choice not to respond or, in fact, to reject the comparison based on actual reasons. I agreed to one of yours: the GPIO. If you used the GPIO from a 500, that's a perfectly good argument for why a laptop can't do that for you, although we do have USB-connected GPIO options based on Raspberry Pi's microcontrollers which could be used in place. You chose to participate in a debate about whether the 500 was better or worse than a laptop. "Mind your own business" is not relevant to such a debate, especially when it now appears you're using it to defend your use of an argument that had no validity which you originally wrote. You argued ARM was better, I asked you why, and your only response has been that you want it and I should stop asking. You can do anything you want because you want that, but that does not argue that it is better.
My primary objection is that didn't make any sense. If I tell you that my laptop is better because it's got a Idnic-brand trackpad controller and yours has a different brand, you would have reason to ask why the difference in controller brands makes any difference when you generally don't know or care which it is, and if I can't point to one, you would conclude that my comparison is flawed. The ISA run by a CPU is relevant if one of the following applies:
1. You have software that only runs on one of those. The only such software I have with that limitation is limited to X64.
2. There's a difference in power consumption or battery life as a result. The 500 is not particularly power efficient when compared to laptops and, being a desktop, you're probably not running it off a battery.
3. There is some other feature that the ARM chip provides which the compared one does not.
You can choose to run anything you want for any reason you want, but if you're making a comparison, adding limitations that don't have any effect just to make your preferred choice the only qualifying option doesn't make any point. If having an ARM chip in there delivers some benefit which the comparison with an X64 chip wouldn't get, then tell us. Otherwise, it's as useful to the comparison as only considering computers whose case is red; you can decide to only buy red computers if you want, but it's not going to prove to us that red ones are better.
In that case, I have good news. They have exactly what you are asking for. It's called a Raspberry Pi. I know this because that's what I've done. You could have all the power that this box has by buying a 16 GB Pi 5B and connecting the hardware that allows you to connect an NVME drive to it. You could have done that before this thing was ever released.
I don't really understand why people like the 400 and 500 so much, because from my perspective, it's basically the same as my Pi with a keyboard of my choice plugged into it. There's one more cable, but it's not like the 500 works wirelessly anyway. The only explanation I have seen is nostalgia, which I have to assume is not the only reason people choose that model or they wouldn't have successfully made three different versions of it. Still, the keyboard part is optional because the core product is still the computer board itself.
I think this machine is quite well-priced. I was expecting to see a higher number given the components they added to it, given that assembling a similar setup from a Pi itself would be a similar price at best. That said, when you're actually comparing those things, are they all actually relevant to you? GPIO I get, although if I had a keyboard-shaped Pi, I probably wouldn't be using those as much as I do on my Pi boards. Raspberry Pi's support is very important when comparing them to any other ARM board, because I am tired of having custom kernels that only work with a distro of the manufacturer's choosing, but when I compare that to X64, it falls short because I can generally expect that I can use any distro I like because the firmware and other low-level components are standard. With the Pi, I still have board-specific images with individual patches, and while having those is a lot better than not having them, not needing them is better than both.
And as for it being ARM, do you get an advantage based on that ISA or are you just mentioning the difference to eliminate that other option? I would understand it if you have something compiled for ARM which you can't get recompiled for X64, but do you really? If not, why is that a factor for you?
Having done a little, though undoubtedly much less of that than you did, I have concluded that the specification problem indicates that the goals of that research are flawed. It tends to boil down to making two programs and then mathematically proving that they always do the same thing since specifications that are so detailed that you can prove a program exactly follows them tend to also be detailed enough that you can compile them to running code, and even that is prohibitively difficult for anything very large. Using programs that produce one mathematical result from a finite set of inputs can work with that, but those are the programs for which a small set of test cases usually already verifies that they are correct, where verification is not perfect but is good enough for almost anybody.
In production, the kind of correctness that has the most effect involves interacting with other systems. For a program that connects to a network, offers a bidirectional API, and controls some machines, we want to know that nothing bad will happen if the machine breaks in various ways, if unusual network traffic is sent, etc. These are not compatible with mathematical proofs in most cases, since "nothing bad" can't be encoded to a set of numbers.
You may want to review how many people the businesses that did these things on paper employed just to manage paper and how many you would need for the increase in clients and activity since then. Paper is not cheap. You might also want to review how many mistakes were made with paper that wasn't easily organized or modified. Paper isn't easy after you have enough of it. Once you have a point of comparison, only then can you decide whether it's worth making that change anyway.
"I immediately came away wondering why Google would bother with [...] an OS that tethered you to an internet connection and became practically useless offline."
A few reasons:
1. They thought something super locked down could be sold to schools, and they were right.
2. They already have a lot of control over web standards, and this would make anything they put in them the requirement if you wanted Chromebook users to be able to execute your code.
3. They have a bunch of online software and little offline software, so making people unable to run a competitor's offline version means more people will end up using theirs instead.
4. The more time online, the more ads you will see and the more data they can collect to claim that they can target those ads.
This doesn't feel important because the law's symbolic and unenforced. The city has no way to tell how long you used your phone or what you used it for, therefore nothing happens to you if you ignore them. Consider how you would feel if this was an actual law and they required or got your usage data in order to enforce it. Would your opinion change?
In my opinion, although I would be willing to ignore it as it stands because I can't fight everything, I do see it as an invalid law which is needlessly paternalistic. This kind of thinking is how you end up with things like the OSA, and there are many politicians who think they do have the power to make and enforce such things, from time limits to not allowing moderation of stuff they like (currently not legal there). If it wouldn't be acceptable if they were more serious, it isn't now.
That would depend on the definition you use for state-backed attackers. Although there's still argument over attribution and UK-based ransomware operators appear to be the leading suspects, Russian ransomware groups have been named by some people. Even if it was them though, it's not clear whether it's fair to call those Russia waging a cyber-war. If these are criminals doing it for personal financial gain, even if a government isn't arresting them, does that make it an act of war if their government isn't suggesting targets or providing resources? I'm not sure I have an answer, but there has to be some level where that doesn't apply, otherwise a prosecutor missing somebody turns that criminal into a government-endorsed mercenary.
I agree with you, and so does Perens; in fact, he specifically added a term in that license forbidding users from referring to "post-open" software as open source, and while that term doesn't specifically mention "free software" as also forbidden, he would agree to that. When this was first discussed, he and I had a discussion about that in these forums.
Why it's associated is simple, though. Perens had a lot of interaction with software under many licenses, including many versions of the GPL, and he has decided that this has failed and should be replaced with his post-open thing. I disagree with him on that, I think for similar reasons that you do. I see licenses such as this one, and there are many ones with a similar spirit that have been created by companies abandoning real free or open licenses, as effectively proprietary licenses but pretending not to be and not pretending too well. I would like to advocate for more support for true free or open software, but because of how those licenses work, that support would have to be voluntary. If you make it involuntary, it's no longer open, because you have to remove freedoms to do it and those freedoms is why I view software as different. I would, in most cases, rather have an actual proprietary thing over that; at least they're not lying to me about my rights and, since it's owned, there's probably a clearer relationship I have with them.
It can be, although mirrors are much more common than P2P directly. The reason why mirrors are better is that the files being downloaded are usually individual and relatively small. If the user's downloading a file which, compressed, is 1.3 MB, the overhead of tracking peers and sending a manifest which is probably about 100 kB from a centralized system anyway doesn't save much if any time. Mirrors, both public and internal, can distribute the load geographically and are quite common. When assets are particularly large, P2P is very common.
Red Hat's distribution model is mostly unrelated. The contraversy with them is the license terms they add to the GPL, effectively punishing people who exercise their rights under the GPL. Red Hat has enough money from revenue to cover their own distribution and the public infrastructure for things like CentOS is something they can afford from some of that.
As I understand it, it used to be relative to the wage level for the job concerned, so the candidates were supposed to have offers above what a typical person doing the same job would do. Now, it's specifically only aimed at the highest wage levels regardless of job. Therefore, you should see more H1B candidates getting in for those jobs that paid well already and fewer or none for jobs with a lower general level, regardless of the relative availability of US residents capable of doing either job.
Generally, it isn't that hard to have work done in one country have results in one or more other ones. If you wanted to add another layer of laws which exists to detect that a person outside the US is doing work which is earning money in the US, you'd introduce even more paperwork than if you wanted to tax offshoring jobs. At least when you're taxing offshoring, there are specific people whose employment and unemployment can be tracked. It's still hard, but there are only so many of those. If you're tracking work, you'd need to identify which countries benefited from each email and PR I wrote today. I'm not even sure what you would do with the result if you could calculate it.
That depends whether a new filing requiring a new payment happens when they switch employers. If it does, then there's no demand shock, but anybody is now more locked into their current employer because it's a lot more expensive for them to change jobs. One of the criticisms of the previous system was that they were already locked in because, unless they found another employer very quickly, they would be required to leave.
A lot of places I've worked use one piece of software for text messages and another one for video ones. The only time I've seen it done differently was with Teams users who did both with that. Why should that be the case; after all, Slack can do video calls and most video platforms can do text chat? I can see a few small reasons, but most of the time, I just have to use what they set up and am not asked to judge it (programmer, not IT).
Intermediate calculations absolutely aren't fine with anything like that. Let's use a simple example. Let's say someone borrowed half a million pounds at a 7% annual interest rate, paid monthly. If we calculate the monthly interest rate correctly, you end up paying exactly the amount specified. If we calculate it with four significant figures, you pay £41,433.35 too much. Let's take it up to 6 sig figs. Now, you pay £486.41 too little, which you might be fine with but the bank won't be. To get that below a pound inaccuracy, you need 9 sig figs. To get it below a penny inaccuracy, you need 11. If this is a larger loan or a different random interest rate, those could end up being even larger.
How far? Because they were checking a spreadsheet against a calculator. Calculators can have bugs too. Do it on paper and the chance that someone misreads a handwritten character or makes a mistake somewhere along the line significantly increase. Where does it end, because it's eventually got to?
I expect the office workers to change how they work to accommodate reality. In the case where it is easy for me to change that reality, I will do it to save them the effort, but when that is not possible, they can often change more easily than reality can. Using your example although it's not the strongest for my point, I do expect that they will work around the way the power grid works. If they need a bunch of power-hungry things, I will still tell them not to put them on a single circuit and have a single switch that starts them all up simultaneously because the grid doesn't respond well to it. Why not? Technically, someone could put the electrical infrastructure in place to handle that kind of spike, but that's harder and more expensive than expecting them to remember that they have multiple switches they have to use for subsets of the equipment. I think they should be and generally have been capable of remembering that and doing it.
I expect to be able to tell people when their work needs to change to deal with some situation. An IT manager should already understand much of this, but if, for some reason, the CFO absolutely needs to change their behavior because of something related to load balancers, I will explain what change they should make, because it's likely to be smaller than changing how load balancers work. If I can easily change the load balancers so this is not a problem, I'll do that instead, but this is not likely.
And if that's the level of difference we were talking about, I'd agree with you. But it's not. The difference between "spreadsheet" and "table" is much simpler, even if they both have cells. Tables are for displaying things in a grid without making you format the grid. Spreadsheets are for taking automatic action on interrelated data, some of which may be displayed to you in a grid. I could see an argument for having embeddable spreadsheets within documents, but they would still be a different thing than tables.
This is weird, because I agree with everything in this last comment. I just have trouble making that work with your first one:
It was designed to do one thing: return plausibly human-like textual responses to textual queries, based on a corpus of human-generated text. That's all. And they do that well. They work according to their stated design aims.
They are sold as being able to do a lot more than that. They don't. Therefore, I hold those who sold it responsible for their lies.
Your argument requires that the products people can buy have a "stated design specification". What is the "stated design specification" of ChatGPT? All the text the average user sees defining what it is is from marketing, not a technical spec. The reason is that there isn't and never has been a specification for what that product is, not from the creators, not from the marketers, because they don't have one. One of their components is a thing that guesses words, but that's not the only part in the product people are buying. They're buying the whole thing.
To continue the toaster metaphor, one of the parts in that does not have the stated design specification of "make toast". The part that does most of the work has a stated design specification of "produce heat when electricity is passed through". Whatever you do with the heat from that part is your decision. The customer expects the toaster to make toast because that's what the whole system does. Complaining that it doesn't is not fixed by pointing out that the heating element does exactly what it was intended to do. Those developers who build this software fall into two groups:
1. Developers who primarily work with the word guessing part and are talking only about it. These people are not lying, but their papers about the word guessing part are not talking about what people are actually buying.
2. Everyone else, who knows full well that what they're telling people their software does is not what it actually does. There are many people employed to work on other components of an LLM-based system. They don't get to argue that customers are just buying a word guesser when they're specifically employed to make it more capable. And, some of the time, they do. The word guesser is rather bad at doing any mathematical calculations, but some wrapper around it can make it capable again. Not efficient, but at least correct. That's a thing they intended and a thing they sell. That is part of the stated design specification to the extent they have one. Developers know this, and that includes developers of the word guesser part. As soon as they make a point relevant to the product rather than just that component, they are as culpable as the rest.
I can blame it on the writers of the software who consistently lie about its capabilities. By your logic, I can't blame software or hardware for anything at all because they all do a perfect job of doing what they do. Even a broken toaster does the job of setting the kitchen on fire in a very efficient way. In some respects, you're right, because neither are animate so neither controls what it does, but we're splitting things up too far.
When we blame software, we're blaming the entire infrastructure around it. If I have a problem with Mac OS because it lies and says an unsigned package is corrupted and incompatible, that's not blaming the if statement in the code; it's blaming the Apple engineer that wrote it and the management chain that told them to. The LLM does not do what it is being sold as doing or what its creators say it can do. The component works as it was set up to work, but that's not the level that users think they're interacting with the software because A) they're right, they're interacting with that component through a thick layer of other software and B) the writers did not say that was the intended purpose.
Not if you consider the report from mrdavidsanders who uses the same hardware you do running the same software the article's talking about. If we accept both statements as true, then the difference is the Surface, not the operating system. If we assume one of the statements is false, we don't have anything other than our own prejudices to tell us which one to disbelieve.
Windows on ARM use UEFI, so they are the easiest machines to try to run generic ARM Linux images on. Compared to all the SBCs with their own custom version of UBoot or occasionally not even that, there's a lot more portability. I know one person and have seen reports from more who do this. So far, that has not been sufficient reason for me to buy one when most AMD64 computers don't have any guesswork required.
"How do you calculate the cost of 1000 Chinese man-hours vs 1000 Silicon Valley man-hours ? Do you count them at the same rate ? If giving the end result in dollars, one would expect you did."
Of course I didn't. If you measure the cost in money, you compare the hours based on how much you had to pay to get the hours. If you accomplished it with workers getting paid less, then your cost is less. I'm not sure why that wasn't obvious or why you assumed it would go the other way when monetary cost was the specific branch.
Or you can try counting labor hours, keeping in mind how mythical those are. It won't help too much with total cost because there are a lot of inputs that aren't labor. Counting money already didn't cover everything but at least it was somewhat easy, and by restricting yourself to counting hours, you're just making it worse. For example, there were at least three stages in a simplified development of this thing: 1) write some software to work with the training data and manage the GPUs used to train it, 2) run that and produce a core LLM component, and 3) write more software around it to add things like "reasoning" capability and the general guard rails. Only some of step 3 could be written while step 2 was running, but they probably didn't fire everyone while waiting for the result of step 2. The hours put in during step 3 were more valuable than those put in during step 2, but they were probably paid the same.
You only need to include those prices when you're comparing to someone who has, or alternatively, you can exclude those prices from theirs as well. To do otherwise is announcing that you are infinitely more cost-efficient as I am at repairing lawnmowers because you had a spare blade and I had to buy one. The spare blade, incidentally, is the only cost that's at all relevant, since you could repair a lawnmower equally well without decorations in your house or indeed the house.
People misinterpreted the announced price as the price for training the model they were using. They compared that to the cost of training other models. That number was not for all the training, thus their comparison was bad. They had two options:
1. Include the cost of training for both models. This gives a relatively standard comparison, going from raw training data to completed model.
2. Try to remove all but the reinforcement part of both models. If they do that in slightly different ways, the proportion of the above cost could be completely different, meaning you have a faulty comparison.
3. Include that for one but exclude it from the other. You have no comparison at all.
It's not hard if you're comparing two things accomplished using the same methods. Yes, different amounts of human labor were used, but in both cases, those humans were payed salaries or wages for their work. If you're just comparing based on how much currency had to be removed from your bank account for the goal to be accomplished, it's not that hard a comparison, because Chinese companies still pay workers and electric bills.
If you were trying a larger cost, complete with externalities, it would be much harder. Comparing different power sources including environmental impact or government subsidies could add complexity. However, it would add almost as much if you were comparing two projects in the same country which could easily have used completely different power sources. The labor calculation is a little easier as long as the people building the product were paid, which Chinese workers are.
That depends on exactly what kind of captcha was circumvented. They kept changing the types to break the people who automated solutions. Of course, those with the worst intentions tended to be people who expected to make some cash from whatever they were being captchaed over, so they found the most reliable option of all: find someone who has an internet connection but doesn't expect to be payed very much and see how cheaply you can convince them to sit there and answer captchas all day when your software tosses them over.
Hiding from law enforcement really isn't that easy. Among other things, there are relatively few countries that don't have an extradition treaty with the US and the UK, and they can still definitely extradite you anyway without a treaty if they feel like it. You have to find one which won't extradite you, treaty or no treaty, and most of the countries willing to do so might not be where you want to live. Alternatively, you can find one willing to not be very clear on who you are so that you can be there and not be found.
For example, Russia doesn't have an extradition treaty with either country and is well-known for not extraditing criminals there, but they don't do it because the Russian Constitution says that Russian citizens can't be extradited by them, no exceptions. They might not anyway if they didn't want to, but if the people we're looking for are citizens, they definitely won't. If you're not a Russian citizen, getting into Russia is no guarantee of anything. You can be an Edward Snowden, for whom granting asylum is a way to annoy the countries Russia's annoyed with, you can make a case that you'll be useful, or you can be a person Russia doesn't want to deal with. In the latter case, you're getting deported out of Russia to make them not your problem, either to the country requesting your extradition because they're trying to be helpful or just to your country of citizenship, which in this case would be the UK.
Three questions:
How expensive do you think EMP weapons are? Let's call that X.
How expensive do you think the parts of a drone that an EMP weapon would destroy are? We'll call that Y.
Now, with D being the price of a drone you just buy and P being your value of not being in prison for shooting off an EMP weapon in densely populated areas, do you think that X+Y+P < D?
The metaphor doesn't work. Code itself can't take actions. There's no such thing as locking code up, and to the extent that I can imagine such a thing, I can do it very easily with GPL software. I've made modifications to GPL software which you can't read for the simple reason that I never gave either the code or the binary to anyone else. That's as basemented as anything else could be. That happens all the time for businesses that run the stuff in house or, in the case of GPL2, in hardware products they sell. And exactly the same thing happens to them; modifications don't integrate well with their private ones and they often end up behind the times.
The freedoms involved are on people. Users, developers, etc have different rights and responsibilities. GPL is a more restrictive license in that it requires more from developers than something like MIT does, but those restrictions are designed to increase the quantity of software using that license. Each dev chooses what level of restrictions and freedoms they feel suits their concept of how they are happy to let others use their code with the restriction that, if they used someone else's, their set of choices may be reduced.
You may not, but there are plenty of people who do. No amount of pretending that what you want and what they want must necessarily be the same will change that. There are people who are willing to purchase proprietary software if they don't have an open source alternative, even though they won't have the right to modify and distribute. There are even people who will choose to purchase proprietary software instead of using the open source variant, sometimes for justifiable reasons (it has features we need, the open source one doesn't, and I'd rather pay for what I need now than try to write it in myself) and sometimes for worse ones (something vague about support or security).
If you want Linux to take over in corporate environments, you have to deal with the fact that many such people work in them. Expecting to change every business from running proprietary applications atop Windows to only ever using open source is going to be much harder unless you're making the open source software whenever it doesn't already exist. I've done that to a few small things before, but I'm not signing up to do it for everybody.
Your objections either make no sense or are simply incorrect.
"I think that applies to any OSS licensed code."
Incorrect. If, for example, something is released under the MIT license, I can add code to it, not release it to anybody, and be totally fine. It takes extra license terms to require that I release modifications under the same license or provide source.
"There’s nothing in GPL that makes one donate code back, even if you onwards distribute a binary."
You're drawing a distinction between "donate code back" and "release code" which does not exist and did not happen in this case. There is no requirement to upstream code, as in making sure it's included. There couldn't be; that would be infeasible if upstream doesn't want your code. That's also not what happened. The code that had been written was not released publicly until lawsuits were threatened, and when it was released, it was merely published, not added to the mainline kernel by its original devs. Someone else copied it and integrated it with modifications. The important part is that, once it was released at all, it was released under a license that allowed someone to merge it into code run by others and continue to maintain it. GPL requires that you release code if requested by someone with the binary, and it requires that you use license terms that let it be merged back. Not everything does.
The promoters you're referring to weren't corporate sales. Bill Gates probably did do that at some point, but when he was selling Windows 95 to people, he wasn't having board room talk. He made some speeches for large audiences, and I don't actually think they were very charismatic. That is not why Windows was adopted in offices and Linux wasn't. If you need people who can do corporate sales, Red Hat had plenty and they now have even more because IBM does mostly that, Canonical can find some, and I'm sure some Linux kernel people could manage it if they wanted to which they don't. A single figurehead who is good at speaking isn't the same thing. People didn't buy Oracle's database software because Ellison made a nice speech.
Because, when someone wanted to use Linux, the network stack wasn't good enough, so they had to write their own to make those things work together, they had to release that code or break the license. Once they released the code, it could be included and built upon by everyone else. The first good implementation could be used by everyone rather than kept as a proprietary advantage. Similarly, Linux provided enough good implementations of other stuff that someone wanted to use it for networking equipment rather than build all those other parts from scratch. Both sides got something simpler which they were able to reuse, but if the license had been more or less restrictive, that might not have happened.
"I don't imagine the chap wandering around Gallilee and reputed to be the deity's terrestrial representative or embodiment had two denarii to rub together let alone bags of shekels."
If we're arguing this theologically, he was connected to omnipotence, so if he wanted to, he would have. Also, this is the guy who received gifts of gold, along with rare stuff that presumably could have been sold, upon birth. I don't remember stories of him using either method to spend money, but that's not sufficient evidence that he couldn't have. If we're arguing it historically, it becomes much trickier to identify any particular person or what his resources would have been, again insufficient evidence to prove poverty.
True, but that's not very different from most other options that would be considered. A custom application with plenty of logging and code in version control is much better, but basically nobody is considering both options. Those who have available programmers that can be assigned to build that aren't going to decide not to bother using them, and people without them aren't going to hire that team and do the setup when Excel seems to get the job done. These are generally two different types of team or organization, and the one choosing Excel doesn't have a similarly convenient way to do it. Those who understand the problem may try to set up change tracking so that they can audit any changes made, but that isn't simple and it has some gaps.
Of course. You can, and it actually does a reasonably accurate job if you're looking for details. If you had a long manual, prompting it on that manual then asking questions can often generate relevant data. There are two remaining problems.
Reasonably accurate doesn't mean always accurate. It messes up less when told to answer the question using this known-correct data and refuse the question if unanswerable from that data. It still messes up sometimes. It depends on your tolerance for trial and error.
And that's not what people would use this for. This would attempt to get the opinion of the bot on new things which have no defined answer. Based on what I've written here, what do you think I think about the moral responsibility of parents, to pick an unrelated question from another article I read today. That's the kind of question that AI avatars would be asked, and now we're no longer talking about something with a factual answer. And if we are, for example if the training data did include some statements about parental responsibilities that could be paraphrased or quoted, it'd still be one level away from pure guesswork when the user requested specific instructions relevant to their situation.
Perhaps I'm not understanding what, other than simple, you want your bootloader part to be. The rest of the system should probably be handled separately; expansion busses are completely unrelated. From your initial argument, I understood that you wanted directly booted operating systems with no bootloader in the middle. Now your complaint appears to be with the load speed due to loading from slower storage. I don't know what problem we're trying to solve or why this is what we're doing about it.
If load times are the issue, I'm not sure the place you're looking at is the right one. Mostly, I don't care about boot times. So it takes my machine 20 seconds to turn on from cold. I can live with that. I could live with it at two minutes, because I rarely turn it off. When I do, well plenty of things I do require me to wait for upwards of two minutes occasionally. But I have dealt with a situation that might be a closer fit to your desires, namely building an embedded device. I was trying to build this around an embedded Linux stack, but users aren't exactly going to be pleased with an item that takes 30 seconds to turn on. I started to figure out how much stuff I could remove from the boot process, either entirely or at least postponing it so something user-facing would come up while those parts were still being loaded in the background. The firmware loading process was one of those annoying things I couldn't easily remove. However, the firmware loading process was at most 2 seconds and often much less. Copying a smallish kernel image into RAM and branching to it turns out not to be that intensive. Loading that kernel and running through the hardware discovery and initiation process is the slower part.
Because some people actually want a standard firmware on which you can start whatever compatible software they want. Your solution works great for something where you only want to be able to run the software that was built into the thing. If you want to do some other things, it starts to break down, and if you want to run anything, it breaks down completely.
Updates are no longer optional. Things change more frequently. Even if programmers were all granted superpowers and never wrote insecure code again, people would still add features and not want to buy new hardware. Yes, that includes buying new ROM chips and manually opening and replacing them in all the hardware they have, when rewritable chips cost the same amount or even less given that's what we've been building for so long. We don't have to. People don't want to. Device-specific versions also makes any kind of update more painful as Android demonstrates. Why do security updates have to be device specific, pushed by the manufacturer? Because they didn't standardize enough. If the manufacturer stops caring, you stop getting patched. On desktop operating systems, that's not how it works; the people writing the patches have to explicitly do something that your hardware doesn't support or they have to block you. Windows 10 is ending support, but it's doing that for all things simultaneously, not requiring a lookup table to figure out that yours actually lost it in 2023 but never told you.
You could try to make a better standard, but as long as you're advocating that we go back to no standards, you're going to have a hard time convincing people other than manufacturers, and they're only interested because it makes it easier for them to make their hardware obsolete faster so you have to replace something that would be perfectly acceptable with new software they don't even write.
By definition, no, because if you only have one key, hard-coded, then there are fewer opportunities for someone to sign something you don't want signed. However, is it enough less secure that you care given that, unless you built the board yourself, you won't control the key that's hard-coded into the board anyway. If you're designing your own hardware that must not run any software other than the thing you want it to, maybe this would be a reason not to use portable firmware, but for pretty much anything else, this is not a problem people really need to concern themselves with.
What is the point you're trying to get at with that? Because there appear to be two problems with your implication, assuming you had a point at all:
1. That was a bug. It was fixed last year. Patch and that won't work.
2. The alternative is firmware with no verification at all, meaning I can do the same thing and not have any restrictions on it because there's no signature checking. Some people prefer that, but they don't pretend that it's safer.
I don't think that's what specification means. The people building the mouse did fail to follow the Bluetooth spec, which did not allow for the name they chose to broadcast. Their having chosen the name didn't make a specification, just a mistake. If it did somehow, Windows does follow it by means of this lookup table. Either way, anything they created, they do follow.
What specification created by Microsoft would that be? The requirement that Bluetooth device names be UTF-8 encoded is Bluetooth SIG's. The people who made the Microsoft mouse did make a mistake, but not on their own specification.
They are far from the only place to have done this. About two months ago, I was dealing with a similar problem where a device would refuse to connect to WiFi networks whose names weren't only using ASCII characters. WiFi SSIDs can be any bytes (up to the length limit), there's a flag to tell devices to interpret that as UTF-8, but whether valid UTF-8 or not, this device refused to connect. I'm not sure what part had that failure. The UI components available to me as a user didn't seem to have a problem displaying the name, but something in the stack was refusing to do it. That means either the manufacturer's own code wasn't handling this properly or the embedded Linux WiFi library they used had this problem. Those requirements have been part of WiFi since the beginning (non-ASCII bytes) or for fourteen years (UTF-8 flag), and yet, there's not total compatibility. Character encoding breaks far more than Microsoft stuff.
"Even if you measured it against this week alone, that's an uptime figure of 99.85% which I'd be surprised to see any other ISP give you."
Interesting. You've got to move to where I live, because I have an ISP that has managed not to go down at all this week. Or, for that matter, last week. Or this entire year. Your comparison suggests that 0.15% downtime is normal. It's really not.
For many people, a small outage like this is not a big deal and they'll get over it. You could have stopped there, because something going down for a few minutes isn't a big deal for most users. By deciding to make this comparison, you now appear to be trying to justify this as being normal far more than it is.
"You could try that approach but I think you'd have trouble finding someone called Debian."
No, you wouldn't. Any of the three nonprofit entities that accept money on Debian's behalf, one of which is EU-based, are targets. That's the problem that came up when the EU tried putting in security requirements without talking to enough people who knew what they were talking about; they risked putting unrealistic requirements on everyone who wrote code, including open source developers. While those who do so on a purely volunteer basis might have escaped it, anyone taking money, operating a legal organization of any kind, or both would be easy to regulate. If you don't want that to happen, you need to consider it explicitly in the regulation to avoid having a default policy intended for companies applying to everything organized.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
