Posts by doublelayer 11559 publicly visible posts • joined 22 Feb 2018
I had the same theory. CircuitPython would make sense for that. In my experience, it can sometimes reboot itself a couple times on connection which rapidly disconnects and reconnects that drive. The interface code tends not to care about this too much, though if it's a serial connection there's more work to handle it than if it's sending HID events. The OS that is trying to mount and unmount things often likes it less.
That report, and the sources behind it, have poor sourcing for the statistics they provide and those statistics don't represent the claim from the article. When they say that 96% of commercial code includes open source components, they have no way of knowing how many code bases exist and would almost certainly fail to consider many of those that don't include open source components because they couldn't know about them. Not that the number is wrong. While it's probably lower than that, it's still going to be a very large percentage because libraries and dev tools are the most likely things to be open with many companies releasing or contributing to those. That's because those things aren't the thing those companies are selling. The product code that they make their money from is far less likely to be open source.
I think a lot of network admins, at least many I've met, don't care, especially on a guest network. As long as you're not attacking their infrastructure and not degrading their network, a lot of them are content to ignore you. Security cares more when someone does it from the non-guest networks because they have to tell whether it's malware or not, so they're more likely to stop such activity, but usually more to eliminate the possibility of risk than because they consider it a problem worth caring about.
I've occasionally needed to VPN out of my company's network, albeit into other company or partner networks. You could detect which VPN I've connected to and identify whether it's a trusted one relatively easily, but it's more complex than all VPNs being unexpected.
You are mistaken. The hash is computed on the destination, not the source. One reason is that, if the hashes from the destination were compromised, computing them on the source means an attacker can instantly log into every account by sending the pre-stored hashes. The transmit password, compute hash on destination flow is what is done in almost all flows, from HTTP logins to SSH, and you can verify this very easily by looking at the traffic sent and watching the cleartext password zoom by.
Encryption on that channel means this is often not a big problem, but that and machine authentication of the destination are the advantages of passkeys. Only by knowing the real differences between the methods can you decide whether you think one is better. If you assume that passwords do something they don't, you'll have an incorrect basis for comparison.
Ah, I see what's happening here. This is a test to see how much a relatively unimportant comment board can stress out people who know what they're doing. We appear to have quite a few people who don't understand what hashing passwords protects you from (recovery of the passwords from the data on the remote service) and what it doesn't (retrieval and replay of the passwords from the ephemeral communication between an authorized user and the remote service) and that there are places that don't hash passwords even though they definitely need to, and all on a place where the readers are generally expected to be knowledgeable about IT. This is one of the main reasons we have security problems: smug people who think "hash" is a magic word meaning nothing bad can happen with passwords if you use it making the same mistakes over and over, whether about passwords or something else. If you don't care about this, that might be sufficient justification, but if you think hashing the password means it can't be seen during communication, then you are wrong and you will be wrong until you learn how it works.
You know you can generate passkeys yourself, no corporation involved? A service can choose not to support them the same way they can choose not to support any passkeys at all, but the structure does not require any third party at all, let alone whichever corporation you think is mandated. There are a lot of annoyances with passkeys, but there are a ton of people here who seem to think they're something completely different than they actually are.
How do you think passwords are verified? The hash is what is stored at the remote end, if they're doing it right. Even then, we frequently find that services store passwords in plain text or encrypted but not hashed, you know, services with only a few users and no technical staff like Facebook. But how does the service verify the password when you log in? It still involves the user sending a string for verification on the remote system. Encryption in transit makes interception harder, but not impossible. I'm holding out hope that I'm misunderstanding what you're saying, but it's looking like one of those people who heard about hashing passwords and doesn't know how that works and what it does.
A passkey can be synced with equal ease as a password and doesn't require any specific service. They are long enough that, unlike most passwords, you are unlikely to be able to memorize them. If you're using a password manager already and relying on passwords you don't have memorized, you are no more independent with your approach than you would be using passkeys.
Because a password gets transmitted to the service you're logging into. Anyone who can intercept it has the password too. The external service also frequently receives the plain password and you are relying on them to throw it away every time when they no longer need it. A passkey is a cryptographic key where the secret part you have does not get transmitted, so neither an intercept nor the external service ever sees the bytes you have which allow access.
In hindsight I'm sure he's asking the same question. That's why it's relevant to consider the approach, what was done to put him at his ease, and how to be more wary if it happened to you.
There's a lot of friction with VMs. It's not a simple or fast process to spin one up with all the tools you need and keep it around. You have the choice of taking a few hours to install and configure the software you already have on the base machine inside the VM or keeping gigabytes of VM disk images around for next time, the latter more annoying on a laptop and a Mac where upgrading internal storage is difficult or impossible. If you do it lots of times, you may have base images that speed up some of this, but it's still an annoying process that even those knowledgeable don't frequently do unless they think they need to. That doesn't lessen the need for doing it, but I hope we can be honest with ourselves about how often we incur this pain; do you go through this every time you run any open source code?
The benefit of a story like this is as a reminder that preparing a VM for situations like this could be useful and as a warning about how far scammers can be willing to go. Neither the article nor the victim claimed this was impossible to prevent or detect.
The UK already taxes that. This is a special tax for tech companies above existing ones for any international company operating in the UK. It mostly exists because those large tech companies have a lot of accountants and lawyers specializing in finding every way to legally not pay tax, and possibly some illegal ones but it has not been proven. They have an easier time of that because many of their products are intangible, which makes it easier to define value in ways that mean they're not taxable in the UK.
I still think this tax is a blunt tool which doesn't really fix the problem. The inclusion criteria are too arbitrary and basically just names a couple large companies as the only ones covered, making it quite easy to slip out of this tax for everyone else. It seems that the better approach, identifying the loopholes that are successfully used to avoid taxes but shouldn't be and then removing them, is too much work for politicians. The blanket tax also has international trade problems since it is specifically targeting specific companies from one country, which when others do it is considered a violation of trade treaties. With the US, that's not a major problem as they have already violated every trade treaty in existence so can't hope to get remedies in the WTO when they've broken the rules far more actively and substantially.
Not quite, so far only the first method, the most theoretically powerful one, was ruled illegal. He has a whole catalog of other ways he thinks he's allowed to set tariffs, the second of which is currently in place. That is why there are still tariffs on current trade with the U.S. even as they're trying to figure out what to do about the last round of illegal ones and why there are more court proceedings about attempt number 2, and if those are struck down then they'll move on to law number 3 that looks like it gives some power over this.
The sales promises add credence to this possibility. They can't tell us what can actually be done over an HDMI cable, but they can promise that their device blocks all the threats. Given the complexity of HDMI as an interface, I can believe that there are problems in HDMI stacks which could be exploited, and if you knew about them, then a device that looks for them and blocks them would guard against those threats although one that looks for them and sounds an alarm would be more useful. But that wouldn't be threat-agnostic unless it simply blocked some channels, and those channels presumably have a point or you could block them yourself. Maybe it's as simple as disconnecting some things that they assume people buying this, who are probably using monitors in an office environment, probably aren't using, assuming that those pathways could be abused somehow.
It sounds like they've got a Mac in dark mode but want Thunderbird to be an exception without changing everything. I'm not sure whether that's possible to configure. While in principle there's no reason you shouldn't have that desire and it could be implemented with a follow-system/light/dark setting, they're still taking the complaining too far.
Well, I got a surprise today. I wouldn't have thought you would support this or express any of the very bad arguments you've just used. You'd think that someone who covers open source and participates actively in the comments section here where people use pseudonyms almost all the time would understand how many people do not want everything they've ever said tied permanently to their identity and how there are websites that benefit from having comments.
This is useful background, but I'm still a bit lost on what the solution is supposed to be. When they stop building an XFCE-based version, then those extensions will be orphaned anyway. The only way to continue work is to start building on the source, and it seems that most of these have the source publicly available, meaning anyone who wants, including those who previously built them with Zorin, is free to do so. They can also form an organization to manage this, but since Zorin's dropping the entire version, they're probably not going to take a leading role.
It sounds like your desired solution is for Zorin to keep building that version and put more effort into it by simultaneously building a project with everyone else. There's a reason they are dropping that and it's probably not because they hate XFCE supporters, which suggests they don't have the willingness and possibly not the reasonable ability to accelerate their XFCE efforts.
One possibility is that a new user thought it would be good to switch to Linux, went to conversations like this one to decide which distro to pick, grew immediately disheartened, and went with the names they heard most frequently which does include Mint and doesn't include CachyOS. a generally more positive outcome to the usual one, they grew disheartened and put Linux off to next time they've got lots of free time.
The new user reads a comment like this one and has no idea what the problem with Canonical is and why; if it's bad, why so many other distros build around it; what is better about Arch; why, if Arch is so good they should use CachyOS instead of Arch; in short every point you tried to make would have sailed over their heads. A number of them sailed over the heads of people who have used Linux for a while; I've used Arch and Ubuntu and variants of both and I'd still have to guess what specific problems and advantages you care about. So when you ask why people don't do what you recommend, maybe this is a point where you can start the introspection.
"I would like to see, say, Mint and Zorin both donate their tools and customisations of Xfce to Linux Lite, which could then continue to make them available."
Do they have a lot of internal tools they haven't released? If not, couldn't anyone take their code already to do that? It might be useful for those who wrote it to make an easier transition process or even go over there to keep working on it, but you write as if there's a copyright issue or the code's not available.
Your response makes no sense. Of course we aren't talking about secondhand refurbs; that's why neither of us mentioned it. Why did you bring it up now? Everyone buys a computer for specs at some level which is why those cheap Chromebooks aren't on every desk. Someone needs enough specs to do their job. If a low-end machine like the Neo is enough specs for you, then buy it, but don't pretend it's comparable to something with far higher ones when making comparisons of value because if you didn't need more, you wouldn't be considering the 13 Pro, and if you did need more, the Neo wouldn't be sufficient and would not be your alternative. Even with Framework, there are cheaper models with performance closer to the Neo, so you are deliberately picking two very different machines and the comparison will never be valid.
Your point that Framework customers are ideologically motivated is basically true, but it makes any cost comparison less important, which is where you started. You've used a bad comparison and now deny the usefulness of your own comparison. As I stated above, if you truly wanted to compare costs, you could have easily done so with a comparable Mac with the M4 or the M5 for the higher CPU tiers or a machine sold with Windows or Linux which uses exactly the same CPU. That would have been valid, and people deciding how much repairability is worth to them would be able to use that.
That's true, the prices are very different. Also, the base config you're talking about has twice the RAM that any Neo can have, a CPU (Ultra 5 325) that's much faster than the A18 Pro chip running the Neo*, a display with a higher resolution (256 vs 219 PPI), and a touchscreen. Frameworks, all of them, are expensive, and as long as you search for a while, you can find machines from manufacturers with the same specs as a Framework for less. By comparing it to something much different, you have failed to make that very easy point, because using the same logic, I can proclaim that the Neo is ridiculous and let me introduce you to the real bargain of the decade: this landfill Chromebook which costs £99 and you really don't want to learn how that happened.
* The Ultra 5 325 benchmarks 80% higher than the Neo on multi-core. Perhaps you don't need that, but that doesn't make the price less justifiable, it makes you a less likely customer. The Mac with the most similar CPU performance-wise is the 8-core M4. Machines containing that are not as expensive as the Framework but a lot closer to that level than the Neo is.
Fair enough on the display. I'm not sure what you need, but if the thing they have isn't good enough, there are no other options so that's a good reason not to buy it.
For Thunderbolt, the 16-inch laptop does have two Thunderbolt 3 capable ports (USB 4, which is based on TB 3). It doesn't have Thundderbolt 4 support because AMD processors don't, so no laptop with an AMD CPU offers that. I do wonder what you have that Thunderbolt 3 isn't sufficient for.
Some people want to use their laptops for quite a long time but get annoyed when a single failed part means it's uneconomical to do so. This is the computer that makes it easy to deal with that. That said, with the number of complaints you have about every single piece of hardware, I have no idea what you think is normal and must assume you just like complaining about things.
"I wonder when we're just going to accept humans are not secure and built the system around that?"
Probably as soon as one of the people who say things like this explains how you can do that. The suggestion, if interpreted literally, means that you build a computer such that a person, no matter how stupid, cannot possibly do anything dangerous but can still do the things they need done. A person with a little experience of basically anything will notice this as the way that nothing works.
We can implement layer after layer of safeguards. We can make it possible for admins to limit what users can execute. We can implement detailed authentication mechanisms where everyone logs in to a separate account with multiple factors and the accounts are limited very specifically to the activities they are granted. None of that helps if the people who are supposed to set those requirements deliberately choose to not configure the former and create one account with all privileges within the latter. They still sometimes choose to do this because properly setting very granular roles for a user takes more time and causes delays when a user first finds another one they need but don't have, so the insecure option is the easier and faster one. If you can do it better, please do so. If you can tell us how to do it better, I'm eager to hear, but expect that I'm going to question the approach heavily because most suggestions along this line I've seen so far are simplistic and weak if they work at all.
The schools near me I'm aware of have locked doors, but other than that, they are not fortresses. I'm not sure a bunch of locked student phones would be a very tempting target, but if it was, I wouldn't expect physical security to be the limiting factor to someone succeeding there. In the theft case, you have two other methods by which someone might attempt to steal devices. A student who already has access could try to carry out a mass-theft, or for that matter so could a staff member who would probably have an easier time of it. Even easier, students could probably quite easily steal one or a few devices that don't belong to them in the big afternoon everyone pick up a phone rush. The last one wouldn't be too hard to prevent but most methods would slow down the process which could be a problem when you have a lot of students and need to get them to their transport or after-school activities quickly.
From that list, the timetable would seem obviously necessary during school hours although it also seems the weakest option unless the schedule is constantly being changed and people just find out what they'll be doing every morning. The lesson agendas would also sound like they'd be used during class, likely instead of printing copies as happened when I was a student. The online quizzes could be homework or in-class material, but they happen frequently during class time, so I don't think those can be ruled out.
The question is not whether these things are necessary but whether they are currently being done, because until someone changes the system to avoid them, it does conflict with this policy.
Unless they need to sign up every week, it wouldn't be very difficult to arrange a sign up assembly line where students take their phones through, scan the code, then put them in the storage system that's going to be used every day for everyone who brings one. That storage system is going to have to scale much larger now that it's every student with a phone instead of those who misuse them.
I still don't like the idea of putting all of this in a phone-linked app because it makes it hard for any students who don't have a smartphone to see their data, and I don't consider using a parent's an acceptable solution to that. But that's probably not anything you can change, so my displeasure is recorded but unimportant.
It depends how they decide to implement the ban part. My preference would be to create accounts that can be accessed from any browser, but if there must b an app, then it would be quite easy to have an exception for signing up for that service while continuing to have phones banned elsewhere. Whether they're smart enough to do that or not, they're likely not going to enforce it heavily if that's the situation where their ban is violated.
What could be a bigger hassle for school ops is whether schools will be required to confiscate and store phones, since students will likely still bring them for use before and after the school day. Currently, most schools I'm aware of allow students to keep them but not to use them during class, but if they have to collect phones every morning, it will require some system for storing them securely and making sure everyone gets the right device in the afternoon which, though possible, is likely to be an annoying exercise for everyone involved. I don't know whether there's a sufficient problem under the "penalties if you take your phone out" policy which justify the stricter one.
The difference seems pretty clear to me, the law requires "intent to kill or cause grievous bodily harm", the jury decides they have "common goal to cause serious harm or death", those align. Ransomware operators usually have a goal to get money, not to kill or cause the physical injury that the law requires, which would make it manslaughter by the CPS's requirements.
It is not. For example, let's consider what's murder and what's manslaughter in the UK. The Crown Prosecution Service has a guide to explain it. Here's the important difference which makes this more likely manslaughter than murder. One of the requirements to charge murder in the UK is "with intent to kill or cause grievous bodily harm (in contrast to the offence of attempted murder, where only intent to kill will suffice)". If you do something which does kill but you intended something else to happen, that's manslaughter. To quote the guide again: "Conduct taking the form of an unlawful act involving a danger of some harm that resulted in death ("unlawful and dangerous act manslaughter")."
I'm not sure whether it's murder in the US either, except that, from news I've seen, it seems that US states have various conflicting definitions of murder. This has been a problem in cases where someone would like a murder charged under a higher degree but the law has established extra rules which make that difficult, and therefore with a potential 51 different definitions of murder, I'd have to do more reading to find out.
Your complaints are incorrect and illogical. Nobody was suggesting that this would not be a crime, in the US or elsewhere. The question was which crime, murder or manslaughter. Both come under the heading of unlawful homicide, whether in the US, UK, or pretty much any country on the planet.
Not that it matters much to the philosophical idea, but wouldn't the correct charge be manslaughter rather than murder, since although the criminals caused the death through their actions, they didn't do it intending the death? A lawyer could demonstrate that they might not even expect the death, as many ransomware incidents fail to kill anyone, which would make the murder charge even harder to prove. I've heard some US states redefine murder into a lot of different types which might apply, but in most situations, I'd think a manslaughter charge is a more certain one for ransomware operators.
Okay, I'll ask, what do you think it means? Their meaning, that people who know they could get arrested if they do that and nonetheless take the risk to their detriment, seems clear enough, and assuming that the people concerned would prefer to avoid being arrested, seems to work well with the definition I've previously used.
I suggest it's not the most useful for them either, since if they can't measure actual usage, it's harder to project the long-term performance of the vendors. This report mixes spending on cloud and spending on software, so if you're trying to limit yourself to databases alone, you have to do more work to figure out how to do that without polluting your data with infrastructure companies who are likely in a different sector of your diversified tech portfolio.
Tell me you didn't read the part of the article that explained that without... It's measuring money paid to a specific company. Since I didn't pay anybody to deploy my latest PostgreSQL instance, they can't measure it on this chart. As others have pointed out, that makes the chart they were able to make not very useful, but it doesn't mean they were intentionally trying to leave out someone to promote an agenda.
Have they really? Can you find me a comment on this article that existed when you wrote yours that expresses the opinion that AI is amazing? I see people talking about those who have come to rely on the product, but so far, I don't see anyone saying the product was good. People can and do rely on things that aren't, either because it's still adequate for whatever they're doing with it or because they don't know better, and those groups can still be disappointed with substantial price increases or product degradation.
"I've come to the conclusion that the only people who find a switch to Linux difficult are Windows-using IT folks of any age."
In my experiences switching people to Linux, the less complex software someone uses, the easier a time they have it. If they spend their time in a browser and word processor, it's relatively easy. If they use more things, the difficulty increases, especially dependent on their willingness to accept change and your willingness to hand-hold them through software they're unfamiliar with. The difficulty I cite when changing organizations is the product of all of those user problems combined and the changes required to get all the institutional processes and tools switched over, which you can do but is going to be a lot harder than switching your basic user was.
To clarify, that doesn't mean that it's not worth doing, just that there will be difficulty and, if you don't plan for it, it can go wrong and be abandoned. If you have a reason to do it which you can explain to management and a plan for how to accomplish it without breaking much, it's likely going to work. Unfortunately, I know a few people who want to do it without those things and, in my experience, they end up disappointed after realizing how far from optional those are.
In addition to the correct posts about Windows partitions, another one is that a lot of external hard drives come preformatted as NTFS. It might be a good idea for people to reformat those when they obtain them, but not everyone does. There's another set of disks some Linux users might want to read and write. More generally though, the reason is completeness, which is why many of the other filesystems are in there. You can easily go a long time without any of them, but when they're frequently in use, it's common for someone to consider it useful to have it in Linux.
Also, people probably didn't object to that datacenter because, unlike the AI ones, it would have a minor if noticeable effect on power or other resource availability or pricing and, for those more focused on ugly buildings, it was already next to another ugly building. Most complaints we see today are less about the tax deals* and more about the costs that would come from the DC whether there were incentives to build it or not, and those costs didn't exist in this case. To politicians, avoiding stupid tax deals is your job, not random citizens' jobs.
* People would also object to them if they knew about them, but it's even harder to find the details for those, especially after the recent wave of legally hiding discussion of them.
No, it would be a lot higher. The smoke detectors have shielding, which you don't need a whole lot of for alpha particles, so a lot of the emitted alpha particles are absorbed inside the detector and never go into your wider home. A bomb designed to spread that around would be quite different, and they would use more smoke detectors for the area covered. However, you can also be a lot higher radiation than a smoke detector without much trouble other than someone coming around to clean it up, so if someone wanted to cause harm through radiation instead of panic, they'd need a very large number of smoke detectors to build their device.
It sounds like the everything public choice might have been about money and advertising. If every free user was only public, then they had a reason to pay in order for their work not to be published to everyone including all intermediate steps, and it also meant that someone who did find a way to use the platform could serve as an advertising case since they agreed to publish it. That would be unpopular, which I assume explains why it was quickly reversed.
I think Clausewitz4.1 has a point relating to demand which may suggest the bubble has a bit more resilience in it. While Microsoft and a few others are starting to push the prices up, they haven't yet completely abandoned subsidizing things, just reduced it. At the same time, the people complaining haven't said they're going to cancel and try doing without, they're still mostly trying to make things work under different limits. That suggests that many of them are willing to pay somewhat more and will eventually do it when the providers give them no chance. It would take a while to figure out how much they have to pay to do what they were previously doing, likely at least a month or two, and by the time they decide whether they're going to do so, it's likely the providers will increase the prices again and start this cycle over again.
I think the bubble popping is going to happen when you have more people focusing on reducing their usage of AI rather than arguing over model choices or user caps. That's especially true because a lot of the load that the providers are making money from are from large companies which pay for token usage, so while noisy, the user subscriptions are relatively small, especially as providers keep screwing over those users by taking things away so it costs them less and less to meet their side of the constantly-changing arrangement. When you start seeing many companies that don't use per-user subscriptions complaining, that's a much stronger sign that they're growing unwilling or unable to keep putting up with the increases.
You made that comment/joke last time. It seems quite likely from context that you've got some other language that starts with an R that you have a problem with, but here's something the comments that time evidently didn't clue you in on, we don't know what it is or what problem you're having with it. That's not very relevant here anyway, but your communication is failing.
The last articles I read about this put a lot of the blame on Shopify, for example this one. It doesn't mean they're the only or the largest party doing it, but they do seem to be significantly involved. I don't use Ruby sufficiently to know the underlying causes behind all of these and there seem to be problems at many levels.
That's one problem with Alexa and many other voice interfaces. They're advertised as getting conversational instructions, but they're basically command lines. You only get anything by knowing the specific functions and preset phrases that launch them. I kind of thought LLMs would get integrated with these things eventually to bridge that gap, but instead of connecting a tiny model to a list of functions for intent recognition, the companies seem to have decided that what they really need is a chatbot for conversations which nobody wants. I don't use these myself, but I've watched many people get frustrated at the lack of natural language capability the manufacturers sell these as having.
If you don't like the idea, fair enough, but is there a reason you consider voice interfaces specifically so over the line? There are valid problems with some implementations of them, but the concept has plenty of reasons for some people to like it some of the time and a smaller set to use it very often.
"It's one reason I'm keeping our own setup, which needs renewing, mostly analogue."
I don't think Bluetooth is the problem here. Even if everything was analog audio, if it's being driven from an active phone, it'll still ring for an incoming call. Most phones on silent will still play the ring sound through any audio, cabled or wireless, because the software assumes you're not within vibration range and want to be aware of the incoming call, but even if you disable that, they tend to interrupt the playing audio so the incoming call would still silence the music. The problem is what is used to play the audio and the interference of other software on that, so that's the part you should implement differently.
You have misunderstood what happened here. The LLM did not find the vulnerability. The vulnerability was already known and publicly fixed. All the LLM built here was code that could work with the vulnerability that had already been discovered, documented, and for which there was code changes available that make it clear what it was. You're giving it credit for something it didn't do and that impairs your argument about nobody else doing it since it's a thing that multiple people can work on independently and possibly are.
