Posts by doublelayer 10476 publicly visible posts • joined 22 Feb 2018
What personnel? Because if you try to answer that question, you will instead start up the blame game. Is it the IT person's fault because they didn't put in some security method? Is it a finance person's fault because they didn't budget for it? Is it a manager's fault because they said not to bother because that's not a priority? Or do we track down the person whose password allowed the initial access and put it all on them? In reality, most situations can be blamed partially on all of those people: the manager said it wasn't a priority, but because the IT person explained it badly to them and because the finance person wouldn't pay for the staff or systems required, the finance person couldn't pay for that because the budget was set by senior management who didn't allocate anything because they didn't get told about the issue from the first manager, the IT person didn't build something out of the pieces available to them but because they weren't given the time, and the user entered their password on a phishing site, but wouldn't have done so if the IT people had put in a better email filter or more phishing training, and anyway that initial password wouldn't have allowed the attacker full access if the IT people had more inter-system security methods, which they didn't have because the finance person wouldn't pay for hardware, and they didn't build in software because the manager didn't give them enough time, because ...
That might be convincing if I could think of anyone who actually would. Yes, I know that some people are stupid enough to put some kinds of semisensitive information in a form, but I don't think there are many, if any, who will put something like their passport number into a form just because there's a box for it. Probably the most sensitive thing I can see someone actually putting there is their mailing address, which I wouldn't do and will probably lead to spam, but it's not as bad as some things. What specific information do you think people will be angry about telling the government but willing to put into a Facebook form? I can't think of anything.
"As for "makes it tough to dump iOS for rivals", isn't that pretty much how MS operates with their Office suite?"
Not really. I had Word and Excel, I generated documents with both of them. I then decided that I didn't really need them, so my next computer didn't get them. I installed LibreOffice instead. I simply open the same files with that and used that software instead. It handled them fine.
And no, if you find a file that opens correctly in Office and doesn't in LibreOffice, that doesn't mean that it's Microsoft's fault, because I do have one file that didn't work correctly in LibreOffice. That particular file had been generated by a different version of LibreOffice. Sometimes, it's not Microsoft's fault.
If you have a different kind of lock in in mind, I'm willing to hear what you're thinking.
No, you can have a closed OS. You start with either OS, and you don't flip any of the switches that open it up. You'll know them because they're the ones buried at least two levels deep in the settings where, if you try to flip them, you get a warning screen. Voila, closed OS for you. If you don't want to install something from outside the manufacturer's store, then don't install anything from outside the manufacturer's store. It's really quite easy.
I don't think it is. Patents are applicable to any industry, and encrypted code is a technique that can be used in anything. The SSPL's fields of endeavor thing is more obvious, because it specifically mentions SaaS providers as having different terms to anyone else, but the GPL doesn't have different rules for encrypted code depending on what you're using it for, so the same terms apply to all people.
Mostly because linking into GPL is something programmers choose to do. There are two important elements to this which I will take separately:
1. Programmers, not users. The SSPL comes into effect when you run the software on a computer if you use it for a certain purpose. The GPL does not care when you run it or why you did it. In fact, you are perfectly free to include the GPL software in your software as long as you don't distribute it, I.E. to use internally. You don't need to educate anyone putting the software to use on what the license means. You only need programmers that might modify or use it in their own software what it means. They have probably seen open source before, so they already understand what restrictions apply to them.
2. Choose to do, rather than find that they've done: If you choose a GPLed dependency, you know you did that. When you pick something off of GitHub, you know that you'll have to read the license because it can be something proprietary that you are not allowed to use, so you know when the terms apply. You can understand the conditions on what this applies to, because it's anything you're linking this with, so you know what you have to put under GPL if you go ahead. With SSPL, neither applies. You may not know whether you are in the set of users that have to put software under a certain source, especially because all you did was install it on a server. If you decide that you are one of the group that has to do that, you don't know what comprises all the software the SSPL is demanding, and it's mostly going to be unrelated stuff written by other people (which you couldn't put under the SSPL anyway). Unlike the programmer and their own code base, it's the user trying to list all the pieces of software that come under a nonspecific category, which the average nontechnical person, even a Linux user, has no hope of doing. Even the most familiar person will have to spend a long time sorting things in and out of the list.
Many of us who care put some importance on the Open Source Definition. The GPL meets this definition. The SSPL specifically violates this part of it:
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open source software.
It also violates, both in letter and in spirit, this part:
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
This is what I care about and the reason why the SSPL is not open source.
The GPL requires you to distribute your modifications to the software under the same terms. The SSPL requires you to distribute basically every bit of software you run on the same computer under the same terms. The GPL can be complied with, you just might not want to. The SSPL is intentionally written to be essentially impossible to comply with. It's not just that your entire cloud service software stack has to be SSPL-licensed. That would be bad enough, but it is theoretically possible. The dependencies, the software you got from other sources, and depending on where someone tries to draw the line, system firmware, would have to be licensed as well. It is intentionally written so that buying the proprietary alternative is the only choice that is feasible.
No, I don't expect people to understand that, especially when they react as if free speech is somehow a lesser thing. The freedoms available with free software are more than just not paying for the software. Yes, you can make me pay for a copy, but the freedoms that Stallman advocated for, and he was the one who popularized that phrase, mean that I am within my rights to give copies to anyone I like, I can do it for free, or I can charge them and not give you any of the money. That's a core part of the freedoms: the freedom to distribute. He often made the distinction to clear up the situation for people who understood it as "software for free" and got it mixed up with what we call "freeware" (I.E. here's a binary, you pay me nothing, what do you mean source code). Requiring people to buy it from you so you're compensated for the work is not what he was talking about there.
We need licenses that say "use this if you will keep it free but if you make money you must give us a percentage."
There are many and you can easily write another one. Don't be surprised when it doesn't count as open source. I'm not just referring to the OSI, because I don't see the OSI as a perfect judge of such things. I value their <a href="https://opensource.org/osd>definition</a> more highly, and I can evaluate by reading the license whether it meets the definition, kind of might meet the definition, or definitely doesn't meet the definition. The "pay us if you make money" bit is very contrary to parts 1 and 6 and can be and likely is contrary to parts 3, 7, and 8. Specific licenses, such as the SSPL, also are contrary to part 9, intentionally so so they can claim not to be proprietary.
This is important to me and may be to others. If you don't want to be free or open, don't be. There is nothing morally wrong with proprietary software. Many proprietary databases exist, and there is no harm in making your business on selling another one. Oracle seems to make plenty of money doing it. The reason I use an open database, most of the time anyway, is because I want to avoid having to deal with the licensing disaster. For instance, I have many Postgres installations. Sometimes, it's because I really want to use one of the many features that Postgres has and other databases don't, but sometimes, I just want a database where nobody will ask to audit my licenses or exactly what I'm using it for and if that's commercial or not. When I write code, I decide when I've done that whether I want to sell it, in which case I don't release it or I put restrictions on the license, or whether I'm comfortable giving it away with the knowledge that I will likely not be able to sell it. I can try to sell support, and that will work on larger projects, but it is not guaranteed. If you want to sell it, go and sell it. Just don't pretend you're not.
"At least China is smart enough to regulate its own AIs,"
If China's regulation actually did anything useful, that might be a convincing argument. It accomplishes two things:
1. The AIs are less likely to tell you anything the government wanted you not to hear enough to check for it.
2. It means the Chinese government gets to approve or deny AI models for any reason or no reason, so they can control any company trying to make them.
Crucially, it doesn't ensure that the models are accurate, or good at their jobs, or not dangerous to the user, or not going to make certain crimes very easy, or anything that we actually want to prevent. Whether you can do that at all is not a certain question, but China's regulation is not doing it.
I also don't think it's fair to say that countries other than China are not smart enough to regulate; the EU, UN, US, and various individual countries have talked about or actually passed regulations, but they don't know what exactly those regulations should be and what they've done tends to be nearly or entirely useless. If you can come up with a regulatory idea that would work, they already have an appetite for regulating it, so it would be pretty easy to get them to adopt your better set of rules. If you've got one, I'm all ears, because I don't have one.
"if somehow an AI could be trained for deliciousness and generate the optimally delicious recipes based on a set of ingredients."
That's going to be one of the harder things to automate. There's a lot of subjectiveness with whether a given collection of ingredients are delicious or noxious, and some people will fall into either group. A lot of successful recipes use trial and error. For example, I decided to make a certain dish and just improvised a recipe. The result was...edible, and it didn't taste terrible, but it was clearly not going to win any awards. Still, I could see that there was promise in it, so I started to adjust the amounts of some ingredients and some times. I wasn't going back to the drawing board, I wasn't putting in completely different things, just trying what would happen if I used different proportions and more heat. I think it helped. I might serve it to you and get a negative response though, so all I've proven so far is that I like what I eventually came up with.
The AI can't do any of that. It can probably suggest a possible recipe, but perfecting it will require some people who can explain what they like and don't like, and if it's supposed to appeal to a large group, you need a lot of them.
"It is certainly being less wasted than doing nothing in the landfill..."
That depends on your perspective. The hardware is in use, but that isn't really any better or worse, and it is using power, which is slightly worse. Whether it evens out depends on what you would have done otherwise. If you would have bought new hardware to do the same job, it's probably better. If you would have opened it with existing tools, probably slightly worse.
The harder it is to fake, the harder it is for you to determine whether a real person is real. If you're looking for entropy, I can replace the tilt sensor chip with one that fires off random numbers from a certain formula. You have to develop increasingly complex hueristics to detect that, and my chip can advance as well. In the meantime, your real users will be doing all sorts of stuff with their phones which will generate different levels of tilt action. If you're not careful, you'll eventually refuse some of them for not moving enough or moving so much that you think it's a fake chip.
There are some methods that can work a little better, but the more reliable they are, the more likely they are to be invasive and annoying to your users. For example, you could use the phone's camera, have them scan their face, and have them perform a series of actions you print on the screen using graphics that change a lot so they're not easily scripted but the human eye can easily distinguish. This will keep out a lot of bots, but it will also keep out a lot of users who cannot (E.G. movement problems, vision problems) or don't want to perform an odd validation dance to use your app. The simpler you make the methods, the more likely someone is to be able to automate it.
What I meant was if the phone needs to act as a phone, I.E. sending or receiving calls or SMS messages, which can't be done without a valid number. That is an obvious reason to use phones themselves. If you're just sending calls, VOIP services seem to work well enough, but if you're doing something that uses SMS 2FA and requires unique phone numbers, that could be one reason why you would need a bunch of SIMs and a bunch of devices capable of using one. This is only one possibility, and for the reasons in my first comment there's reason to wonder if they're actually doing it, but that would not work just with a network connection over USB.
That's the subject of most of the discussion in other threads, and for a lot of possible tasks, yes it really does seem inefficient. However, if there is a task that requires a phone, there can be a few reasons why this would be the most efficient option. The obvious reason is if you need to use cellular connections. If you need active phone numbers, you can't do that with a typical server, and the hardware that allows you to connect one SIM, let alone many SIMs, to something that's not a phone tends to be more expensive than just getting the motherboards out of the cheapest phones that aren't selling and using them. The theory is that Chinese dictatorship-linked tracking of phone numbers would make that difficult, but their repression might have some bugs that allow an organized criminal to get phone connections easier than we think.
The other option is that they're using some app that doesn't make it very easy to do anything outside the app. I'm imagining something that has no web interface available, no desktop access method, and actually secures the network communication so you can't inspect the traffic, reverse-engineer their protocol, and poke their API directly. The discussion has considered the ways you could virtualize Android, but in my experience, many of those are limited in some crucial ways, such as being easily detected by applications running in it, missing important system services, or just unstable in the first place. That could make buying cheap boards more reliable than trying to virtualize it, especially if they end up being as expensive as the server you're using. The article's quoted prices are about that of a mid-range desktop, so if you know a good Android VM, how many do you think you could run simultaneously on that machine before running out of CPU or RAM (I'm thinking RAM is probably the worse one, but it's also the cheaper one to fix). If you do know a good Android VM, I'd be interested to hear which one it is, because I've been relatively disappointed with the ones I've seen.
Both you and your first reply have the facts wrong. Just like everywhere else, typical wages have tax deducted when paid, not just at tax time. That's done because otherwise, it's very easy for someone to either spend more money than they should because they have to pay in taxes or to run away with their money and refuse to pay the taxes. The authorities there do exactly the same thing as they do elsewhere. This article demonstrates that. The reason why criminals have taken to finding information on taxpayers and completing their tax paperwork for them is that many people have overpaid their taxes and will be receiving refunds, and the criminals can, by doing the paperwork before the real people, divert that refund to them. Of course, if they aren't getting a refund, the information can just be sold to someone who wants it, so being in the set of people with income that doesn't have automatic taxation* is no defense against this.
* Normal wages have taxes paid before the person receives it. Depending on the status, other types of income either might not (investment income) or definitely don't (business income). Another set of people are reporting that income and paying more taxes on it.
"saying someone has photoshopped something was much easier than trying to explain a relatively new feature on Apple phones and bringing AI into the equation."
However, the metadata indicates that Photoshop, that specific product, was used to edit it and iPhones were not. This gives us two options:
1. It is what you say, but someone removed anything indicating that an iPhone was involved at all in the image taking process and substituted some mangled data pointing to a standalone camera and Photoshop just to mess with us.
2. It wasn't an iPhone, so it wasn't iPhone AI. Something else did it.
Which seems more likely to you?
"The "doctored" photo in question was a matter of minor touch-ups"
I have long considered that my not being a UK citizen gives me the opportunity to gladly not know anything about the royal family, including at times who is related to whom. Still, I have heard more about this photo than I'd like to and you are understating the degree of editing involved. A post by a person who enjoys analyzing photos, not someone who tracks the royal family, notes many edits involving all the people depicted and many parts of them. This isn't a minor edit for some aesthetic purpose. What actually was intended is something I don't have to care about, but understating it as "minor touch-ups" is no better than overstating it as "definitely indicates that she died in February" or any other unproven nonsense someone might be trying.
"basically, it seems a podcast is just a name for an audio file you can download and listen too offline"
Yes, you have it right. There's an RSS feed around it, so it is a feed of audio or video files that you can download and monitor for new ones. That's really all there is to it. And yes, Apple did start a lot of it so they got to get the "pod" in the name, but they don't make iPods anymore, it's a very open standard that doesn't give any power to Apple, and the one thing they still have (a popular but optional database making it easy to find podcasts) is open to everyone on all platforms, so can't we give them the name thing?
Whether you like that or not is up to you, but the concept is not complicated. Podcasts are just another way to listen, and there are quite good ones and a large number of crap ones, just like everything else on the internet.
Laws are written to enforce moral things. Maybe your philosophy is that they shouldn't, and I certainly can point to laws that enforce morals I don't share and would like to see change. If you're trying to pretend that laws are not written to make some forms of morality required with penalties if you don't act in the way they consider moral, you may have a weird idea of what makes a politician promote one or a voter demand one.
"Trying to claim that their product is defective, when it was operating as designed is like holding a car manufacturer responsible for a driver intentionally running down pedestrians."
You have made this argument before, but it does not represent what the case is about. The defect they're talking about is that the recommendation engines promoted violent material, and if you ask the companies that make the algorithms, they will tell you that they don't intend to recommend that stuff. They will say that because the alternative "yes, we definitely build our engine to recommend violent media when we think that'll make us money", sounds evil. The reality may be that they don't intentionally try to promote it and they may put a little effort into trying to detect it, but so little that it doesn't actually get removed from the recommendations list unless it's extreme and obvious. If this is behavior that the producer says they don't intend and behavior that the plaintiff says is harmful, then you can make a case that it's a defect. It's not a perfect one that's obviously going to win, but that's not the only legal problem these lawyers have.
The analogy to a car or a scalpel is wrong. When talking about the moral responsibility, they can be valid arguments to suggest certain views, but when arguing the legal one, they are not because they don't represent the argument being made. The scalpel example, in particular, is very far from the situation because using a scalpel as a screwdriver is ridiculously far from intended use, whereas using a car to move forward or a social media algorithm to see content is exactly what they were built for.
The question is not about common carrier. They are not common carriers, but they don't have to be. The protections of section 230 apply to "information service provider[s]". The distinction is that information service allows them to make the information public and show it to many people, including those who were not deliberately targeted. In order to prove this case, they'll have to do one of the following:
1. either prove or form a distinction between "information service provider" and something else,
2. demonstrate that the law itself contradicts some other law or right,
3. demonstrate that the platforms do not have to be deemed a publisher to have liability for this case.
I think they're kind of going for option 3, but I'm not their lawyer or a lawyer, so I can't say that for sure. They're already close to the already decided cases using 230 in a related way, so they'll have to have a new argument or they'll lose from that precedent.
Without 230 or something similar, there might be a lot less everything. If I could be sued for literally any comment someone chose to post, I might be a lot more cautious about letting people post anything that was slightly negative on one of my sites. If I write a post about a product existing and someone comments that the company's build quality, security practices, value for money, or anything else was bad, do I want to take the risk that the company concerned gets angry about that comment existing and try to threaten me into taking it down? We all know that some companies are that irritating and quick to use the threatening legal letter.
Yes, that would also significantly reduce the junk out there, including the really unpleasant junk. It is useful to know what the downsides are when considering it, however.
"where is TikTok?"
My best guess is that they're focusing on services this specific attacker used and he didn't use TikTok? It's a long list as it is, but maybe he did list all of those as places he found material that made him want to commit mass murder. That restriction is the only reason why TikTok couldn't fit into the list. Whether this suit will prove viable is a separate question.
My point is that, if you're building from source, you probably aren't reading the (quick check) 110 files containing 18002 lines of Go, not counting anything retrieved when running the build scripts, or the build scripts, or the frontend stuff written in TypeScript and some JavaScript. Then, you download a massive model which probably just has an input and output stream, but you can't be sure, and I have a feeling you're not building that from source because that is training and it's quite expensive. Treating the installation script as the dangerous part when there are tons of other parts where something dangerous could be is not very helpful. The script can be very straightforward, and it is, and that proves nothing about whether this could be malicious (yes) and whether it is (probably not, but how would I know).
Not if that exe was basically running its own curl to get the real code. A lot of installers work that way, and although they're not my favorite, they think there is a reason because it lets people install the subset of components without, for example, including the translations and fonts for a bunch of languages the user doesn't want in the initial file. Malware can easily use a basic downloader which won't look dodgy until the specific sample has been reported, and it just downloads the more suspicious code and executes it from memory.
Installing this program on Linux (or anything else) will involve one of two things:
1. Downloading a binary from someone else's server and executing it.
2. Downloading a rather large chunk of code and compiling it.
And running it involves one more:
3. Downloading a model, either from their server or another one, and running it.
That's three methods to run malicious code if they are malicious. Saving the script and reading through it won't help you when this line from the real script
curl --fail --show-error --location --progress-bar -o $TEMP_DIR/ollama "https://ollama.com/download/ollama-linux-${ARCH}${VER_PARAM}"
Can download any binary. If they're doing something malicious, the malicious part would be in that file, not this script which I can read in a minute. If you don't trust them, you can try to build from source instead, but I somehow doubt you're reading every file to make sure you don't think anything in it is malicious.
They listed some specific uses. Most of those uses are not good things, but they are specific things that one could do with them, including more tailored spam campaigns. I think what you're asking is why you would want to use one, and it sounds like the answer is you don't want to and you don't need to. I don't need to, and I probably won't, but if I did, it would be to play around with it, not to do something particularly useful.
That said, I can see some situations where some models could be more useful to the average user. For example, there are text to image models that sort of work. Sometimes, they end up making weird, illogical images and sometimes, they don't even get that far and make images that are a bit more horrifying, but sometimes they also work. I cannot draw. If I decided I wanted a picture of something created, running a bunch of prompts and seeing if I could get the computer to spit out something good enough might be a faster or cheaper way of getting the image than commissioning someone with real art skills to do the job. This is not something I'm going to do any time soon as I have not needed an image created, but it is a case where I could see someone deciding that running a local model sounds like a good idea. I don't know how good the local versions are, so they may be disappointed with the results, but the decision to try it could be logical.
"if they "infringed" upon the patent before you started selling anything that uses it, too bad, it's considered two entities arriving at the same conclusion independently of one another."
That's a recipe for invalidating a patent by watching for it to be filed then quickly making something crappy that can be argued to use the patent. I don't object to the idea, but that detail is open to a lot of abuse if the patent is real, so it may need some more tuning.
I don't know the person, but those questions, while hard, are the kind of thing you expect from an interview. If you have had problems, very public ones, getting advertising for your social media platform, and advertising is the primary revenue source for the thing which has been running at a loss for basically its entire life as a company and a big loss since you took over, that is likely to come up when someone is interviewing you. You should expect that it will come up, have a PR person come up with a nice answer that makes you sound confident and the business sound successful, and have it ready for that point in the interview. Having someone ask those questions when you control the situation means you have the power to respond exactly how you'd like. Clearly, he didn't plan for that and took offense at the questions, but they're not outlandish or offensive questions.
If you are hiring a reporter to interview you, expect to be asked questions. If you don't want that, hire the reporter and don't have them interview you, or hire someone who will ask you only questions you wrote. Musk didn't plan this out, but it would have been a perfectly workable way for him to learn what the questions would be and have good* answers for the lot.
* Well, not all of them would be good, but they would be the ones that sound best in his situation. For instance, his answer about drug use may not have been great in our opinion, but it was confident which is probably the best that one could hope for with that situation.
Your distinction between a password and an identifier is firmer than it is in reality. Theoretically, a password is also just an identifier, just one that theoretically only you have access to. A good enough fingerprint is also something that's not trivial to look up and provide, so it's also something that you have uniquely easy access to. The problem comes because it's not as easy to guarantee that nobody else has it. For something that needs harder security, that risk makes a fingerprint a bad choice. There is a reason that my fingerprint reader remains unused. If you're using a system where your password is an easily guessed string, as many people do, that password probably isn't more secure than a fingerprint.
There is nothing intrinsic about a fingerprint that prevents it from being a password, though it is prevented from being a good password. The analogy to a name is flawed. I know the names of many people, so simply asking for the user's name is not a valid password. I do not have the fingerprints of any person other than myself, so they are not useful to me as identifiers.
If someone is going to the level of cutting off your finger, your password is probably not too secure either. If I'm next to you with a sharp knife and I say "tell me your password or I'll cut off your finger", it's likely you will tell me the password if I sound like I mean it.
What I was thinking of for fingerprint compromise is someone going to the effort to get a good impression of your fingerprint, then applying it to something the reader will recognize as a finger. Depending on the quality of the reader, this can be really basic or it can involve more effort, but it doesn't involve physical harm.
"On what basis *should* that be much of a priority (ignoring all the twaddle about "year of Linux on the desktop" from a small number of strangely shouty people and lazy headline writers)?"
It depends on what you want to see happen. If you want to see an option that works if you make it, and that's it, then it shouldn't be a priority. If you want to see it win out over Windows, as some clearly do, then it should be one because users won't switch without it. Whether they will switch with it is another question and by no means guaranteed, but it's not going to happen if people are more confused by Linux than they are by Windows or if IT departments decide that they won't distribute Linux machines because there will be something that is prohibitively difficult to teach their users to do. I'm guessing, based on the second clause in your question, that winning over Windows is not your goal here, but it is useful to note it anyway because it is the goal of many Linux adherents who post on this site or in this topic, for example whenever the idea of whether Linux should be installed on corporate desktops comes up.
However, if it is not your goal, there is another reason to try to make it happen anyway: more availability of the tools you want. If more people use Linux, more stuff will be developed for Linux, and at least some of that will be something you're interested in running. More Linux success also means more compatible hardware. Consider, for example, something I'd like to see more of which is open mobile devices, devices where I not only have the freedom to replace the operating system if I want to but where there is a realistic chance that my replacement will boot up because I'm not relying on some component that the manufacturer is hiding the driver for. I'd like this so I have more control over the software I run, so I can keep devices for longer than typical ones get updates, and sometimes because they let me experiment. If you don't want that, you can substitute something similar that interests you, but the parallel is probably still valid. If the operating system I choose to boot on this theoretical open device is something that works for me because I wrote it but doesn't work for anyone else, then it's not that surprising that people don't build devices compatible with it. If it's something that people can adopt without having precisely the needs and skills that I have, then more people will use it, and the more of those there are, the more of them may have the ability to build hardware that makes it better. The more people that the software pleases, the healthier the system of related technology, and as a user of the software myself, I benefit from that.
At least some of this looks to be sites online that list instructions for installing packages that could be installed from the package manager, but the instructions only give the CLI commands to do it. The author of that assumed that a Linux user would be familiar with those, as many of us are, so they just gave instructions for that. I typically install things from repositories from the command line because I have seven terminal windows open already, and so I may fail to consider how many people aren't using that method. The user, in turn, isn't aware that they can read those commands and use a GUI tool to do that.
That is assuming that everything is in the repositories. If it's something that has its own repository, they're almost certain to describe the installation procedure to add that repository to the package manager using CLI commands. I'm sure the GUI applications are capable of doing it, but it's still going to involve finding keys from a site and putting them in a box, and that's going to require more explanation to the user. The set of software that comes as downloaded loose binaries or packages, Snaps/Flatpaks/AppImages, or tarballs with scripts in them, is also large enough that it can cause problems for the unfamiliar user. I confess to being at least partially responsible, because my installation instructions are usually somewhat terse and assume the Linux user knows and is comfortable with the CLI. I don't do a step-by-step instruction on the various GUI options. Maybe I should consider it, but most of my tools are useful to other programmers so it's likely to require action from developers of more user-focused tools.
Not to mention that Liam makes it quite clear that he does exactly this. In another comment, he explains that he uses a Mac but not the app store on it, which means that to install tools other than the defaults for the OS, he installs them by... downloading binaries from websites. Alternatively, he downloads the code from websites, then compiles them with the compiler he probably got from Homebrew, which he installed by pasting a command from a website. Somehow, this method of installing software, the way that almost everything works at some level, is Microsoft's fault and should never be done. Linux may make it easier by having a repository built in to most distros, but it doesn't prevent it from at times being the only available method to install something.
It depends on your security requirements for passwords. There are things where the password is not very long or complex because the user believes, correctly or not, that more complexity is not required, where a fingerprint is as secure. This is valid for systems you control, because if your fingerprint is compromised in some way, you have the freedom to turn off the fingerprint access and use something else instead. There are certainly situations where a biometric is considered more secure than it is and therefore the system using it is improperly configured, but there is nothing in it which prevents it from being used as a password for low-security systems.
"no site that can be trusted will tell you to type commands."
About that: yes, they do. There are still things that aren't found in a package manager's default repositories or that the default version isn't going to work for. There are a few ways around this, but they usually involve downloading a file of some description or running some commands which will do it for you. The file might not be a binary itself, but if it's a shell script, it's no less dangerous. For many users, the distro's default repositories will contain what they want, and I admit that having to use things that are outside it are more often encountered by me when I'm doing more technical things, but there are times when a user might want something that is not in those repositories.
For example, consider tools like youtube-dl or it's modern equivalent, yt-dlp. These things change very frequently because the old versions stop working very frequently. There's a chance that it was never added to the repositories at all, but for many distros, it's probably in there. By it, I mean a version from six months ago that might or might not work. If you want to use that, or a GUI program that wraps it, you will want something more updated. You can download a binary, you can retrieve it from its Git repo, you can get the Python source from Pip, you can find a custom repository that updates the packages more frequently, but in all of those cases, you will be getting some file or command from the internet and running it on your host and if you don't, you won't have the tool. Your statement might represent what should be the case*, but it doesn't represent what is the case.
* Maybe you think that everything should be in the repositories, but you also know that they can never contain everything that someone might want to use. This is especially true when the concept of non-open source software for Linux comes into play. There are some proprietary programs made available for Linux. I have one that I purchased and sometimes install on my machines, and you can bet that it's not in repositories. Their GUI installer is pretty good for less technical users, although the default installation method is still the CLI installation script, but it does involve downloading a binary from a site and using it.
Of course devs like the CLI, as I know from experience as one of them. We like it for two reasons:
1. We spend a lot of our time in it to do our work, so we're pretty familiar with using it.
2. It's a lot easier to design an interface on the command line than to build the graphical UI components. To build a GUI, you have to write so much code and link it together, none of which is the interesting thing you're trying to solve. If you want it to run on multiple operating systems, your tools for doing so are restricted to a smaller number of frameworks, and each of those comes with some restrictions. Yes, we know how to do it, and when it is necessary, we do, but the first version of something to see if it works is usually tested as a CLI program. This is also one of the reasons why you see some apps using web frontends; it's a lot easier to write something that will work well on multiple platforms if you do it that way.
Of course, good programmers recognize when the CLI is a valid option for the program they're writing and when a GUI is needed, and when the program is to be run by nontechnical people, the CLI is usually not a valid option. Even when it's mostly run by technical people, whenever there are too many elements to fit well on the console, it is time to build a good GUI around it.
I don't post or frequently browse Reddit myself, but I do find myself going there and occasionally finding some useful data. From my brief experiences, I have a few reasons why I don't stay there longer, but first, the positives. It seems like a site where people interested in a somewhat niche topic can find others who are similarly interested. This is kind of why I post on El Reg. A comment section where a lot of people don't understand technology gets kind of old when nobody is bringing up anything interesting about news related to technology, but most of the people here are knowledgeable enough to have interesting conversations on a topic I'm also interested in discussing. I have found small forums and mailing lists related to topics of particular interest to be similarly engaging, and the theory of Reddit appears to be that all those forums can exist on one site, making them easier to find and less likely to disappear because the moderator of the forum got bored, stopped paying the server bill, or even more likely just stopped doing anything including allowing any new user registrations. I have found some areas of Reddit that do appear to work like this.
The problems that have made me a rare reader instead of a frequent contributor sound like they're getting worse. I have never been impressed by the interface of the site, and although there were other frontends, I didn't use the site enough to use them. Now, there aren't other frontends because Reddit planned to send massive bills to all developers, and the main interface is still pretty bad. Maybe there is a method to make it less annoying, so I can actually see a discussion thread in an order that lets me follow it, but I haven't used it enough to find out. The other problem is that there appears to be weird criteria about what is on topic, meaning that I've seen both things that appear irrelevant and arguments about something that looks relevant in the same place. The comments above this one make me conclude that this isn't going away. Therefore, I tend to visit Reddit only when it appears on search results where I'm looking for relatively uncommon information. If a Reddit post appears in a search where I'm looking for someone's comparison between two products, I tend to read that because it's likely to be what I asked for. If it appears in a more straightforward search, I skip it.
If Microsoft ceases to exist, their TLD will probably lapse. But you're going to have to wait a while. Microsoft isn't likely to fail in the short term, and even if it changes its name for some reason, the old one will still have importance. Facebook may call itself Meta now, but the name and domain connected to Facebook still has a lot of meaning. The same applies to Google/Alphabet. When they changed the name of their corporation, they didn't change the name of the service. Even when a name is supposed to be retired, the change does not happen quickly. Elon Musk may want us to call Twitter X, but the x.com domain just redirects to various names without X in them, but with twitter in them. People still recognize the Twitter name, and if someone else eventually takes the husk that Musk left, I can guarantee that they'll want the Twitter brand and will probably not care too much about the X one, which is good because Musk is oddly obsessed with it and undoubtedly will want to keep it for something.
It sounds like they are diversifying. teams.microsoft.com is one domain, whereas multiple things *.cloud.microsoft are multiple ones, which can have multiple name servers involved. Not a lot of diversification, but there is some. A major DNS failure probably won't be much better with that, but it won't make it worse.
Since most of the devices we're talking about are using standard hardware like SD cards instead of a custom flash storage integrated directly with the board, that makes a lot of sense. I wouldn't want to have to deal with SD cards, some of which will work with all devices because they have wear leveling in firmware, and some of which can only be used with a filesystem and operating system built to do it for them. I have enough trouble with identical-looking cards with vastly different speed classes, although this is made easier by none of the devices that I see supporting the faster ones anyway. It's a recipe for people buying a card and not understanding why it fails to work in many devices, including Linux machines because they didn't apply such a filesystem when they formatted it. If there's a basic compatibility layer that exposes it anyway, then they'll just fail fast for anyone who didn't format them that way. I question whether the wear leveling software is that much better at extending life compared with the firmware on the cards to begin with.
"remember he is an academic who has never had to earn a living from being a software developer, this combined with a hippie mindset has poisoned open source and our ability to charge anything for it, hence why we have all the open source funding problems we currently have."
I see the problem, but not the solution. Most of the ways that you can mandate payment have an unavoidable effect on some of the other freedoms that I value highly. If, for example, how much you have to pay depends on what kind of user you are, then it's no longer free to use by anyone, anywhere, the way that open source tends to require. It also restricts the freedom to modify and distribute, since the version I changed and distributed still contains most of the work that went into it before, so presumably I have to collect payment and redirect most of it to those authors.
A lot of the suggestions I've seen are, to the user, little different than proprietary except that they can modify the code on their own computers, and there are some proprietary licenses that also permit that. If that's the intent, then, from my perspective, you might as well be proprietary. At least the proprietary authors aren't pretending to be something they're not. I'm open to hearing ideas about how this could be done differently, but so far, I haven't seen one that works, preserves freedoms, and fixes any of the problems with funding.
I agree on the terrorism bit, but not on the cause damage to protected computers bit. I can certainly damage your computer by working only with the software. I can do that in two ways. I can damage the hardware by running intentionally destructive routines repeatedly. However, what they meant, and what we all understand, is that they damaged the computer as a system, a system of which the software is a crucial component. That damage can be repaired by wiping it and rebuilding, but nothing said that damage has to be irreparable to be called damage.
As for protected, of course it was protected, the protection just failed. Your house is protected; it's got walls to protect it from flying projectiles (blown by winds mostly), it probably has fire suppression of some type designed into it including materials that are hard to burn and alarms, and it has locks on doors and windows to make entry harder. If I walk up with a big hammer and a flamethrower, your house's failure to prevent those from doing damage doesn't prevent it from having had protection, just not enough to withstand what happened to it.
If TikTok were to die, I'd be perfectly happy with that outcome, but I don't think this is an appropriate or even legal way for that to be arranged. I oppose it, not because I want TikTok to stick around, but because I don't think adopting the unfair legal regime in question is a good thing, especially if it expands to more countries and more companies. China already has restrictions like this, and I'd much rather see them drop it than everyone else adopt it.
It might work if you set up your account with an EU address and make sure your network traffic always comes from there. Depending on what you do, you may not appreciate the transatlantic latency for all communication. However, if Apple doesn't want you to use it badly enough, they can collect information about your connection (American mobile provider) and GPS location to determine that you're not actually over there, so don't count on it working now, and if it does work now, it can break at any time. I'm guessing that your best bet will be to wait until the next jailbreak comes out and see if you can unlock it from there.
I'm not sure if people in NI get this feature, but I do know that buying it there and bringing it back means you don't get it. Your current location, not purchase location, is used to see if you have the right to use those features, so much that if you leave the EU for long enough, you lose them. I'm also not really sure that people in NI would get it. I understand that there are trade regulations in common with the EU, but it doesn't make every EU law apply, and the DMA would have to be applicable law for NI to be included.
"Q. How would MS know the difference between an "egress" and running a bunch of queries on your datatables that happen to involve exfiltrating all the contents to somewhere else?"
They wouldn't, which is why both are billed and why you have to shut down your account or meet some other requirements to qualify for that bill to be canceled.
"2nd Q. Why on earth did you go cloud or Azure in the first place?"
Well in the case of some of my employers, because they're relatively small, so they don't need enough servers to set up their own server room, and renting them across continents instead of collocating them was considered either cheaper or more reliable (I write code that runs on the servers, not choosing where to put them). I think they could have done better by running the compute-intensive internal stuff somewhere local, but running the public-facing stuff on cloud servers makes sense the way they've arranged it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
