Posts by doublelayer 9378 publicly visible posts • joined 22 Feb 2018
That's not what this suit is about. Using mobile-grade processors in a server is not Qualcomm's problem. The license doesn't say what people may do with the chips they buy from Qualcomm; it says what kind of chips Qualcomm can design with ARM's information. ARM evidently has different license requirements for server-grade chips versus mobile or laptop-grade ones, and that's what they'll be fighting about for the next five years.
This seems unlikely. They didn't shut down 4G, so anyone with a smartphone made after 2013 wouldn't have had to replace their devices. Someone still using an old 2G phone or who adopted smartphones early then never got a new one would have to, but most users had something new enough that they didn't have to swap it out. I think it is partially inflation, combined with the fact that a new phone doesn't really do anything the old phone couldn't do. The same thing restricts the demand for computers, which no longer need replacement to run new software, so they're kept around until there's some serious hardware problem (and longer if the owner knows someone who can fix that problem).
Who knows, maybe some company will take a real AI* chatbot like the ever-popular GPT and attach that to the phone line. While it's busy not solving your problems, you can have nice philosophical conversations that start to get confusing about twenty seconds in. Or, given what's happened with many other attempts, you get something worse.
* AI in the sense that it's not using a script and its responses aren't supplied by the programmers, but created from intensive computations based on stuff it copied from someone else. Not AGI, so in case you were planning on calling me out using a definition I didn't mean, this is my disclaimer.
And this causes a lot of problems. A common scam type involves gaining access to the email of a place that deals with large payments, real estate being popular, so they can change the numbers in an email before the customer is about to make a large payment. If the customer doesn't call to check the numbers, or if the scammers also put in a fake phone number, a large payment is sent to the scammers. One would think this is a thing that we can update, but the banking system often looks like some design features from the 1980s are still left in.
Quite far. If you have money that they say isn't yours, they can do lots of things to get it off you. Holding it in ways they can't break is another crime, and they can apply penalties until you give up the money. There's a reason the successful thieves run to another country and live in obscurity, because if law enforcement has the ability to penalize you, they can find ways to make you change your mind.
Not necessarily. For one thing, having a program which makes web requests is not always a problem if, for example, it comes with an improved interface or other features that benefit from a local program. It could, for example, cache translation results and store them in a convenient local file which some users might value.
For another thing, Google Translate does work offline, but only on phones. You can download offline translation databases which work when the phone is disconnected, though I think the quality is probably different when not using the server's presumably much larger ones. Someone who knew that might expect there to be a desktop application using the same files for offline translation, and if anyone from Google (or a different company with translation software) is reading this, I'd like that, please.
"An understandable precaution, but surely it could present the name prefilled and ask for confirmation that's the patient you want so you don't have to type the whole name again?"
The risk is forming a habit that's hard to break. The user sees that box a few hundred times, and the name's always right. They get very fast at clicking through it so they can get to the important stuff. Then, on time 472, the name's not right, but they click through anyway and the data's misaligned. This gets even worse if the thing's running in a batch mode where it shows multiple patients in a row, because then they could have an off by one error that cascades through everyone else in the list.
This can still be improved by using a shorter identifier, E.G. first three letters of the name followed by the last three letters, although if you implement that, make sure you can handle a name like "Al Hu" somehow without confusing everyone.
Banks often get to assign whatever sequence of numbers they want (if you're lucky, it's just numbers), but if they want to, there are several methods for defending against transposed digits. The Luhn algorithm is popular and freely available, so it's more an issue of persuading those not using it to start doing so. That article does list a lot of places using it to protect against fumbling or misreading numbers.
It's a prefix with plenty of annoying historical uses, but we don't have a different one when we're creating new words. If they said that we were in a state of perpetual "computer warfare", it would sound at least as silly and likely more so. Those of us who work in IT or another computer-centric field may not say "cybersecurity" much, but those who deal with lots of other things in the big category of security want a word for the computer-related parts of it. If it's not going to be cybersecurity, you find another short word for it and convince others to switch.
"Is it too much to ask for a commercial OS to come with maximal security as standard, not something that requires user/admin configuration."
Yes, it is. But fortunately for you, I have such a product available for purchase. It's guaranteed to make your computer unhackable, at least while it's running only this OS. You don't need to touch a single config file or even think at all about what you're doing with the machine to ensure the security. Sadly, in order to accomplish this, the following restrictions are present: you can't store or load any data in nonvolatile memory, you can't run more than one program at a time, and you can't communicate with any other system. I was originally not going to let you turn it on either, but I do like providing my customers with features when I can.
You're asking for a perfect solution, all on a system whose entire purpose is to be among the most versatile data processing equipment in the world. It's akin to demanding a lock that can never be opened, even when the perspective burglar has infinite time on their hands and access to high explosives, and oh yes you also want it to open in at most two seconds when and only when it's you who's entering. If you want physical security, you have to put some thought into what inefficiencies you'll accept, where you'll need security systems, and what processes you'll need to maintain them. Failing to do that is likely to give you a flawed system. It should be unsurprising that digital security has similar requirements.
Were you not aware that a government can target its own citizens? Lots of them have, and dictatorships really like doing it although democracies are distressingly often willing to do the same. You can never attribute with perfect certainty a piece of malware to its creators, but there are lots of methods of doing so that produce better results than seeing that a few machines in Iran are affected and jumping to a conclusion without seeking any other evidence.
In that case, I agree a bit more but I'm still not sure whether it's feasible. You can improve the keyboard, trackpad, case, and all that, but the Raspberry Pi just doesn't work very well with batteries. I've had many battery-powered Pis and, while you can do it, they lack power management features that let them save power and what makes the SoCs on the boards so cheap also makes them power hungry. This model doesn't have terrible battery life just because the battery's undersized (it's kind of small, but not laughably so), but because it's powering a Pi 4 along with the peripherals. I'm afraid that may always nag at the attempts to create a portable machine based around the Pi.
"A laptop chassis is nice to have for a Pi, it would better than a Chromebook in the schools and home. Probably the ultimate thin client for business as well."
Not really, because a few of the specs make this not great for a thin client and possibly even compare badly to a Chromebook (and I hate even thinking that's possible). The largest is the three-hour battery. Students taking a laptop to classes won't always have a recharge socket at their desk. Three hours when new won't get them through a school day and will leave them tethered to a wall when doing homework. It's more likely to be plugged in at a company, but if it's always plugged in there, they don't need a battery, and if it's not, three hours may still be insufficient.
Also, students writing essays or business users writing emails are going to want a keyboard that's at least somewhat comfortable to use, and the review doesn't speak well of it. I don't know how bad this one is compared to other weak laptop keyboards, but if it's worse when compared to that, it could impair productivity.
But why is being part of the Raspberry Pi community important in this case? Don't get me wrong, I really like the Pi and I have a bunch of them, but that doesn't mean I have to use them for everything. The benefit of the Pi is that it provides a supported, relatively open platform for relatively cheap. A lot of cheap laptops with X64 processors will run Linux just fine, meaning you can have a similarly open environment. You don't need the Raspberry Pi for it. The product concept sounds interesting, but there are a few things that make it less interesting to me, such as the three-hour battery life on a fresh battery, which can be avoided with most other laptops.
I guess you hard-code the time that the conferences will happen and find the IP blocks used by hotels or conference locations likely to host them (if not already announced), and then you just check your host's address and clock against that list. I don't really think most malware authors are going to go to that effort when they would probably be better able to hide by finding a less identifiable C&C method. If you'd still like to try it, try putting your machines into a hotel in Las Vegas and mess with your clock so it always shows a time in mid August.
As soon as they announced bankruptcy, I'd start looking and interviewing. I'd keep working there until I got something, and if they came soaring back then I'd still have the option of forgetting about the others, but a bonus wouldn't change that plan. I'd accept it happily, but I'd still assume that this wouldn't end well and that alternatives would be pretty useful after a while.
There are legal things, but not necessarily legal things you want. Anonymous transfers across borders that move quickly aren't illegal even if criminals do use them, and I could see some cases where they could be desirable. For example, if you were sending money to a friend in an area where the existing financial system wasn't working, such as a war zone, you could accomplish it with cryptocurrency. I've never done that, it's likely you haven't either, and you may not be willing to allow the risks inherent in cryptocurrency so someone else can, but it would be legal.
"Orwell back then could not think why someone would install a telescreen without being forced to, but silly TV shows were yet to come..."
I'm sure he could and did. He took the idea from the proliferation of radio and later television, and people bought those on their own. The book doesn't indicate that people were forced to install telescreens at first, and one character did suggest that at one time the equipment was purchased. I don't think the mechanics of how people came to have the equipment were particularly important to him, as how the party chose to employ the equipment was his major focus.
The point is not that Apple created products where nothing similar existed, but that they created innovations on existing ideas that made people want to buy them. The iPod was not the first digital audio player, but it made major improvements on the product which were later emulated and improved by competitors. The iPhone did not invent the smartphone, but it did invent the multitouch touchscreen phone at least to the extent that previous attempts had almost no market penetration.
There's a reason the iPod was so popular and that all modern smartphones look like the iPhone. Apple didn't invent products that made people say "I've never seen anything like that before", but they did find a few that made people want them over the competition. I don't mean to suggest that they did that with every product they made, but they have had a few of those over the decades.
I admit I've never understood pre-decimalization currency, but I don't think your division is accurate at the lower levels. I've lined your list up with the number of pence in each one. If I'm proving my ignorance of the subject, I'm curious where I went wrong.
one pound, 240 pence
ten shillings, 120 pence
five shillings, 60 pence
two shillings and sixpence, 30 pence
one shilling and threepence, 15 pence
ninepence, I have 7.5 pence
four and a half pence, I have 3.75, and this would be the last division, but assuming this is accurate
two and a quarter, half of 4.5
one and a half, that's not half of two and a quarter
If it's about dividing in two and it goes down to a quarter of a penny, it still only looks like you can do it six times, ending at three and three quarters. Of course, this is only relevant as long as a quarter of a penny is important to anyone, which if the pound retained its value today is doubtful. If you can buy something for 0.1p, then I stand corrected, but most countries haven't bothered keeping around units of money that tiny. In another thread, someone quoted a modern price of £1.30 to buy the same as two pence, meaning that in precision terms, the smallest amount of money available to someone then would be worth about 16p today anyway, so they weren't keeping around currency that was a lot more precise.
"I am not permitted to make more than 750h of calls in any calendar month (uh, whut?!)."
My guess is that your line can make simultaneous calls, and spamming that for multiple callers is how scam calls get started. So to either protect themselves from charges of helping a scammer or to ensure you pay more if you want to do it, they're putting on a restriction that's meaningless for a single person but would affect multiple people using the same line. Of course, if it turns out you can't place multiple calls at the same time, then I don't have a clue.
Only if you have good solutions. Otherwise, it teaches people a lot of bad habits. If you learn from a lot of people who weren't able to write good code in the first place, then you'll end up basing your knowledge on what's by definition the wrong way. Yes, some of that would be remembered as the bad way to do things and you wouldn't reproduce it, but other bad practices would probably still get through.
You can make a case for a lot of things being critical knowledge that everyone should learn, but for most things, it's not true. We would probably get many benefits from teaching everyone medicine. I'm not talking first aid and biology. I'm talking about proper medical school training including basic surgery, including practical application as early residents. We also live in a society where laws and contracts are important, so let's give everyone at least a year or two worth of legal training. We live in a world of many cultures, so you'll have to be fluent in at least four languages from different language families. We don't have an extra few years to have everyone do that, so we don't. I'm guessing that, like me, you don't have a medical or legal degree.
We live in a world with a lot of computers. That doesn't mean everyone has to program them. Programming is one of the things that's easier to self-train, and I know many good self-taught programmers out there. By all means we should have resources available for those who want to learn it. I'd even be happy with a mandatory small chunk in the curriculum that introduces everyone to the idea, and they can decide from that taste whether they want to continue on to more advanced work. Training everyone to be good programmers by the age of twelve, on the other hand, is elevating what we like over a lot of more important things for little benefit.
No, you wouldn't, at least not until you could prove they did so well. If, for example, they had you fixing bugs that were all a bit obvious, all revolved around incorrect behavior, etc, you're not competent for most programming tasks. One of the frequent requests of a programmer to modify existing code isn't to fix a bug, but have it do this stuff but faster than it's doing it now. That takes understanding of how the code interacts with the systems and how performance is affected. Many others are about adding features. Some even need functionality started from scratch. They want to test that you know how to do all of that, and if you only know how to fix someone else's bug, they might be able to find better people. If they can't even prove you know that, you're not a good candidate.
"The world could be very different today if every child was competent at programming by age ten or twelve. But I digress."
Right, good luck getting that going. While you're at it, I have several other skills that could be handy if everyone knew it by age 12 instead of some people knowing it in adulthood. I learned it relatively early as well, but not everyone has the interest to do the work required to have that experience, and some people would prefer to spend their time learning something else by then. If you have a miraculous invention that enables everyone to know a lot more than they already do, by all means let's train everyone to write code. If not, let's not force people to do it if they don't want to and are planning to use their time doing something different.
Spin it up and give it a try. I haven't tested it myself, but having seen a few examples, I'm pretty sure it won't be able to read a spec and spit out a program any time soon. It probably will choke pretty quickly on most assignments after introductory courses. We have to train people to write programs because this tool isn't an AI programmer with perfect knowledge, and we need to start by training them on the basics that this one can do because they need the easy building blocks to get started. If we want people to self-train the introductory steps, this is no problem. If we want to use the traditional get-taught-and-tested method, we'll need at least a few occasions where they don't have this to make sure they have a good starting position.
I think this is most useful in the introductory courses. When you're teaching someone how to write really basic functions because they don't understand all the concepts they'll need to implement a solution, you can't just keep adding complexity. You can find simple examples that aren't in common use yet, but eventually you'll run out of good ones. There's a reason that Fibonacci and factorial are always the first two examples of a simple recursive algorithm, because they're easy to understand and write without needing extra knowledge.
If you're making good software developers, you need more than understanding someone else's code. At some point, they'll have to write their own code and it will be in the next class when the problems are harder. They should start writing stuff now, even if the answers are kind of basic.
For most courses, you're right. For introductory courses, the first step probably should be teaching the inexperienced student how to use a tool. Their solution to each problem will be built from language concepts that they have to understand, so it makes sense for the first introductory class to test their ability to use a language. If you don't understand how a loop works, your solution to a problem, if you have one at all, will be hideously unmaintainable, so it's important that everyone learn quickly what loops are and how they're used.
I don't think that will be a problem. In most courses, the first exam is at least a month if not two into the term, so you'd have lots of practice before it gets to the test. Referring to the old homework when doing the next one wouldn't be a problem under any course conditions I've experienced. By the time you get to the test, hopefully the experience of having done what would probably be ten to twenty of those tasks has helped you to understand the structure of a chunk of code so you can reproduce it.
I don't think it is a daft idea. This is a problem for introductory assignments sent out as homework where you can't add complexity because the students don't know enough yet. It's the kind of thing that we can write in two minutes today, so there's only so much you can do to prevent someone getting a simple solution. Even plagiarism without being detected would be pretty easy with this kind of question.
My answer to this problem is like yours: put out those homeworks, perhaps give students a small grade for having turned something in, and give them feedback on how well it worked, but don't grade it. People who want to learn will do them anyway and get good results. People who cheat will get only a few points. Then, give everyone a test on restricted computers or even on paper (though I don't much like coding on paper, it can be done), and grade that. Someone who learned with the homework will do it again and score well. Someone who cheated will probably look at the questions and panic because their cheating tool isn't available. This also gives any student who wants a dry run in case they don't understand a concept, so they can learn it in time. The homework can be treated as a practice with feedback, and the test can be secured from cheating more easily.
Just saw the first links have typos. I was trying to link to these ways of making robots break themselves, already tested by the BOFH and PFY:
Before you do that, check what they're made of so your shots don't end up hitting something too solid and going somewhere else. Also check how good it is at detecting other obstacles that could disable it. Instead of creating a potential safety risk to yourself or nearby people or walls, you could first see if the BOFH's a robot crash still work. Although if you need ways to destroy one that do cause safety risks, the BOFH has some of those too.
There are a few we know of who didn't do something stupid, well not stupid enough that it resulted in their capture. Those people are probably still enjoying their luxurious lifestyle on someone else's money, though, and one part of that is avoiding having us know where they are. The whole fake identity thing probably gets boring after a while, but there are people who do it successfully.
I guess so, as why else would you buy 16 of the things? There's no logical reason why, even if you liked them and wanted some backups, you'd need anywhere near that many. It's not hard to imagine that someone buying that shopping list might not be thinking very clearly, although that's not going to change the consequences of their actions.
Pretty early in the personal computing era. Programs have been called "applications" for quite a while. They even got called that in the days of the Apple II, so the late 1970s works. Shortening that may have taken a few years more, but come on, if you're posting here you're probably in either IT or programming, and you already know how much we like to abbreviate things. We talk about comms, OSes, docs, VMs, configs, and apps. It's a normal term and it's existed for decades. It's just a good thing we're not calling them progs.
"Some programs have more than one of those, and since piping around directories requires standardization we don't have, they don't get used." I'm sorry, I don't quite understand what you meant here. "Piping around directories" -- meaning, lists of subdirectories and their files?
What I was trying to say there is that, if a program reads more than one input stream, for example consuming a directory and all the files in it, you can't simply pipe in it's input because the structure of the files is almost certainly important to the task. If it was critical, you could do something like piping in a tarball, but that would require the program to untar everything which they virtually never do. Similarly, if a program produces more than one output file, you can't just pipe its output to another program because it too wouldn't know in advance how to extract the data it wants.
In either case, the program is going to end up using the filesystem for input and output, leading to a performance hit over having that program integrated with another function which can receive the data as a memory structure that doesn't need copying and probably in that case doesn't even need serialization. Doing one thing well could have a downside to doing two things in the same program, eliminating the need for temporary data on disk.
I get the philosophy, and I've written lots of CLI programs myself that run in just this way. However, the problem in many cases is that those programs don't always work in the ideal way, making some of your comments optimistic.
"Re: "writing temporary data to a disk": we're no longer in the days of CP/M. Windows, OS X, and *nix implement pipes internally, without resorting to temporary disc files."
And some programs use them, with just one input file and one output file. Some programs have more than one of those, and since piping around directories requires standardization we don't have, they don't get used. Sure, we could write a program that opens several pipes and another program that expects to read from that many, but the point is that we'd have to write both programs to expect a situation that's not always applicable. Also, there are programs that don't follow that rule. I'm using one now: it takes a file and you have to give it a path, it writes a much larger file to a path, not including standard output, and in my case, I immediately take that file and throw away most of its contents. That program could be implemented so I could pipe data through, but it's not. I get around the inefficiencies by using a ramdisk to store the temporary file, which is fast but still not ideal.
"You seem to be expecting/hoping that MegaApp X will have all the specific functionality which you desire"
Well more suggesting it's possible than expecting them to do it automatically, but sort of. Having to export a file from one application to another, possibly multiple times, can be inefficient if the original application could add a feature to do the action. For example, printing a file probably should be done by the same program that displays it, rather than having a system-level print application and making that understand every file format you might use. That doesn't mean the application needs to connect directly to every printer, but it can collect information needed to convert the file to a printable version and call the system print handler which only has to know how to pass a standardized file to the hardware.
Or take another example: you could have an email program and a calendar program, and you do the connections yourself. For people who know how to script both, maybe you can get it to automatically do things based on emailed information related to meetings. However, not everyone will do that correctly if at all, and those actions are very likely to be connected. A program which does both of those and understands how to automatically consume responses to meetings, meeting request emails, and the other messages likely to be of use is likely to save more time than two very good programs that only do one of those things.
"Further, MegaApp X likely will not be ported to non-mainstream operating systems. Likely it will be a Windows-only app, and even then, might not work on older OS versions."
That's not really a problem with the size or structure of the application. You can have platform-independent massive GUIs and you can have OS-specific programs that are twenty lines long. Take the program I mentioned that writes a big temporary file. Why don't I just edit the code to fix it? Even assuming it would be that easy, I don't have the code. It's provided by a place which doesn't want to give me the code and hasn't made the format the code reads open, so I have little choice but to use their utility as it is. It's a pretty basic command line program, but if I want to run it on a non-AMD64 Linux or one that doesn't have a new enough glibc, I'm out of luck. Windows is right out with this thing. Anyone can have that problem, and anyone can avoid it.
The examples aren't the same though. Sure, maybe there is someone who has a reason for turning their light on or off from elsewhere, but nobody's even tried explaining why while I'm in earshot and everyone I've talked with doesn't see a benefit in it. I think that's a pretty common view. Self-driving cars, on the other hand, would have benefits for many if we could get it done.
If you could safely sit in a car while it gets you to your destination, you could do things that are now unavailable to drivers because it would impair or prevent their concentration on driving. People could even sleep on their commute. You could also send your car somewhere without you, for example having it pick you up at a convenient location without having to park it there beforehand or go get someone else without having to go with it. The existence of those benefits doesn't mean it will be feasible to make the product, but if you drive, I can almost guarantee you've had occasions where you didn't want to be driving and could have used the features as I described them. The concept still has problems, but it's not as laughably useless as the smart light bulbs.
I'm not them, but I don't think they were suggesting that you prevent that. I think they only meant to suggest that individual tools that do one task may not always be the most efficient way to do something under modern resource limits. An application that uses more resources but can accomplish a task without repeatedly calling programs and writing temporary data to disk may have advantages in some workflows. It's less that you should be unable to chain programs, but that you choose not to write your new tools in a way that requires that approach.
Not only is that common to most DEs for Linux/BSD, but for Windows and Mac OS as well. Using the system UI controls or path system so remote paths can be treated like local ones is pretty standard providing the application developers use them, which is the usual problem. When an application reimplements the edit control, it's not because they didn't have the system one to extend. They just chose to reinvent that wheel. Whether there was a point depends on the application and what they wanted to do with that control.
That would be nice, but it wouldn't fix the problem about security. You can build insecure stuff out of open source components. Quite frequently, the problem addressed in the SBOM requirements is that third-party dependencies, often open source ones, have vulnerabilities and the user of those dependencies didn't update their product. Sometimes, those dependencies have vulnerabilities but nobody bothered to fix them, including the original maintainers. Just making everything open source won't fix any of that stuff.
If you don't trust the kind of governments that can pay virtually any amount of money, then that's a problem but not one a lot of people share. If the government really wants ten thousand licenses, they're likely to pay for them and possibly use the larger contract to get other stuff they want, such as priority for bug fixes and feature requests. They do have some pretty good reasons not to want their computers connected to the public internet so your license server, which they haven't audited, can accept a key and potentially log information about where that license the government bought is being used.
Well of course if you treat them as images, they can be edited. I don't generally treat a picture as an editable file format if it contains a document, because instead of opening it and typing in some text, I have to manually typeset things. You can use other tools to interact with the text layer of a PDF and insert content without having to redo the entire document, which is what I was referring to. A PDF is less editable than a text or ODT file, more editable than a PNG of the document, and a lot more editable than a recording of someone reading it out.
You'll reject files for having security issues in favor of a different format that also has them. Brilliant. PDFs can be edited too, albeit much more painfully, so I'm not sure why a document format that can be both read and edited is such a problem even if you don't intend to edit it. Do you have the same problem when they send you a readme file that's in a format (text, markdown, or HTML being the most popular) which can be changed just by opening it in a text editor? Perhaps you would prefer a bitmap from a screenshot? At least that would be guaranteed not to have security issues if we use a completely uncompressed raw image format.
I wonder if those aren't using Bluetooth after all. That's common on the cheap ones that built their own RF system because they often don't bother with any system to reject commands from other devices using the same channel, but that's part of the Bluetooth spec so anything that does use Bluetooth shouldn't accept packets from other devices. Those commands could cause problems with getting the real packets through if they're located too close together, but that would result in real keystrokes not being recognized, not incorrect ones. The downside to using proper Bluetooth keyboards is that they require the Bluetooth connection to be set up beforehand and if that's your only keyboard, it can be annoying to do it. I think that's why the USB dongle custom RF design is more common.
"you're left with a perfectly good but useless keyboard in 5 months when the "rechargeable" batteries die."
I'm not following this. Not only do I infrequently see wireless keyboards with rechargeable batteries, but when I do, they last a lot longer than five months because you can recharge them. What are you doing that causes them to die so quickly? Is there something wrong with the recharging system? I'd be surprised if you had to recharge more than once a month for those, and the only one like that that I've used lasted about three months before needing a recharge.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
