Posts by doublelayer 10191 publicly visible posts • joined 22 Feb 2018
Absolutely, but if you're comparing it to definitely losing all of it, you can excuse the fee. Everyone paying the fee will get a reminder every time they do it why they hate the person who came up with this idea, because they're being forced to pay to maintain access to their money and if they ever forget, they'll lose it. People hate bank fees which are charged automatically, and making them manual will just make the idea less popular.
Theoretically, there are several possible benefits. In practice, many of them don't actually work. For example, transferring that money to a different country is slow with paper money, and depending on the quality of the postal service, it may disappear before arriving. Transferring it from account to account might work depending on the countries involved, but there are often delays, fees, restrictions, and other things that can get in the way. Cryptocurrency could, and sometimes does, make it faster to send value anywhere, although some of the more popular ones do so more slowly or expensively than was originally advertised. This feature is also useful to criminals who hope to avoid controls, but that doesn't mean they're the only one who would like it. Cryptocurrency's other deficiencies mean that this benefit is not used as often as the less convenient transfer mechanisms that function with the money people have on them.
It's been proposed. It's a stupid idea for many obvious reasons, but it's also easily defeated by exchanging all my money before it's going to expire with others whose money is also going to expire. It just happens that we did similar amounts of work for one another around that time which we feel deserve similar amounts of repayment. Clock reset. It also doesn't do a thing to prevent criminals from using it; criminals want to spend their gains too, so how does preventing saving do anything against them? Of course, you could build in lots of extra features to make it harder for criminals to use it, most of which would be detrimental to and detested by law-abiding users.
A lot of effort has gone into encouraging people to save money because people who have money available when they need it tend to do better than people who spent all of it. Forcing people who want to save to spend it anyway kind of breaks all of that, generating exactly the opposite of the benefits from it. You'd also get some fun bonus problems from people who didn't need to be convinced to save and now face a use or lose situation. You also get two groups of angry people who might want to attack you because either you took away their money, or to avoid you taking away their money, they invested it in something that doesn't expire but wasn't a good choice. True, that second one normally isn't your fault, but since they had to invest or you would have confiscated it through automatic expiration, they'll ascribe any downstream negative consequences to you. Meanwhile, I see no positives whatsoever.
Everyone has their own opinion. In this case, the closest I can get while sticking religiously to your naming options is CheckDLInAD (Verb+noun+preposition+noun). For hiding what he was doing, that name is just so slightly better, but for readability, I prefer his. I do not see a reason to mandate that function names always be imperative phrases. Most of my imperative functions do, but this was not an imperative function.
Perhaps the bigger problem was admitting it. If you're planning to plead not guilty with the hope of not getting convicted, a provable confession is not a helpful thing to have. Of course, it could have been that he thought he would get a better sentence after trial than from pleading guilty, but, although it happens, it's not the most common outcome. There is one thing he did get, though, a long delay between confession and sentence. Maybe that was worth it.
Those would be some of the downsides I was talking about. Most of the time, tariffs have a bunch of those and don't do very much on the three supposed benefits. Often, one or more of those benefits aren't actually benefits. For example, if Trump puts tariffs on TSMC, that will hurt TSMC, a little, but A) it will hurt the US a lot more just by existing, B) it will not much help any US competitor, C) it won't drive semiconductor manufacturing to the US in the time he has, and D) there is no good reason to want to hurt TSMC anyway, so the one intended thing it does do is also bad. This leaves only one possible benefit of the tariff, the government revenues collected from all the people who still need chips made by TSMC and buy them with the tariff in place. That revenue is not worth the pain inflicted on all parties, and nor do I think he really cares about that measly revenue when he can just keep borrowing as much money as he wants. However, he doesn't understand points A through D, so he still thinks it will work.
Other tariffs occasionally have different cost-to-benefit ratios. In general, blanket tariffs will have a lot more downsides than targeted ones, and ones passed after consideration will make more sense than ones instated or canceled based on how you're feeling today. Sometimes, tariffs can be a useful tool, but like a lot of tools, you need to know what situation they're useful in and using them in most other situations is more likely to break things.
Trump thinks tariffs are more powerful than they are. He sees them as triads of success because they hurt a foreign business, promote a domestic business, and earn money for the government. To give him his due, they do all of those things. However, they don't do all of those things equally, they don't last very long even if you keep them in place, and they come with some massive downsides which may outweigh all of the benefits if you use them on a whim. He uses them on a whim.
In this case, he seems to think that putting a tariff on imported chips will be enough to promote local production, and he would be wrong. The manufacturing can't be built anywhere near fast enough for that to be feasible. All he'll get is inflation on anything with a chip in it and anger and concern from Taiwan. There is no cheap way to make your country have a lot more semiconductor manufacturing capacity than it already does. As for loans, I don't know how well they would work. TSMC could already decide to build a fab in the US; they have or could get the cash, but they aren't choosing to for various other reasons. Your loan needs to have enough value to convince them to build the thing despite having another place they think would be more profitable to build it. That means you might have to give them a larger loan than a grant since it's not just about getting access to the capital. Basically the same problem, there is no cheap way to quickly make your country have a lot more semiconductor manufacturing capacity than it already does.
May I suggest you reread the comment? The "lot of things" statement was not a statement on the quality of those things. It was a statement on the quantity of them. In fact, if you dislike those things, the quantity of them would be a negative and you'd hope, in the absence of getting things you did like, to have a person who was not capable of doing a lot of bad things. Their broader point was comparing the quantity of things accomplished to the last time that Trump tried to accomplish things and making predictions on the number of suggestions he makes which will be implemented rather than ignored. This is a relevant prediction if you think he does wonderful new things or if you think the actions he takes are likely to lead to disaster, because it predicts how much improvement or destruction you're going to get.
I have frequently compared the productivity of dictators. In most cases, the ones that are capable of doing a lot of things are the most dangerous ones. It isn't a positive thing if the things are bad.
Since you're comparing a 2024 processor to a 2013 one, that's not much of a surprise. If, instead, we use the Mac Pro tower from 2019, the difference isn't so big. It's faster and uses less power, as you'd expect with a six-year difference, but they receive somewhat similar benchmarks, with the main difference being that the 2019 Xeons achieve them through lots of cores while the M4 has much nicer single-thread ratings.
Of course, that isn't relevant to their complaint, which wasn't about processor speed but upgradability.
It sounds like we agree about the important parts here, but to clarify those where my statement wasn't clear enough:
"Neo4j did not create their own license": They did. They stuck some legal terms together and said "this is the license". They didn't do it well, and they might have done it so not well that their license doesn't let them do what they intended, but they did make a license document.
"they did not ‘have the power’ to add terms while masquerading as AGPL. Note - they kept the AGPL name, FSF copyright, and preamble - that clearly states the AGPL has to be verbatim."
This is where it is unclear. For one thing, they didn't masquerade it as the AGPL. Before any text, they state what they think the license is:
The software ("Software") is developed and owned by Neo4j Sweden AB
(referred to in this notice as “Neo4j”) and is subject to the terms
of the GNU AFFERO GENERAL PUBLIC LICENSE Version 3, with the Commons Clause as follows:
Are they allowed to do that? It is unclear, and the FSF don't want them to, and when the FSF told them not to, they complied. However, that is not the same as masquerading since the modification was stated up front. Neither is it clear whether they can be challenged by the FSF on the verbatim part, since they do include the AGPL verbatim, then tack their clause at the end. As I said in another comment, if I write an introduction to a book but do not modify the content of the original book, you wouldn't say I had edited it, so it isn't clear whether the FSF can or has chosen to exert control over anything else that appears.
In addition, these details only are relevant to a case, which has not been filed, where the FSF sues Neo4J over misuse of their trademark and/or violation of the license to their license. It does not answer what that potentially misused license means. Even if the FSF is correct about all of this, all it means is that they could make Neo4J change it, which they have done voluntarily. It wouldn't necessarily mean that you can apply other terms to the software. Whether you can apply those terms is a different issue, and the chance that maybe you can only exists because Neo4J did not stick their license together well and ended up with something contradictory.
A license does not restrict the actions of the copyright holder. If I license version 1 of my software under the AGPL, then license version 2 as my proprietary no rights allowed license, I am allowed to do this. If I include in my version code that you wrote, licensed under the AGPL, then I have a problem. If it's all code that I created or to which I have obtained copyright ownership, I am allowed to relicense as I wish. This is, has been, and will be central to all free software or open source licenses as long as copyright exists in its current form, and as all of those licenses draw all their authority from copyright, it is important to know this.
I have read both of them, and while both briefs focus on this, and while a lot of motions have talked about this, it is not very relevant to the actual case. Neo4J is absolutely not saying that they used the AGPL, but they interpret it differently so what they think is what it means Humpty Dumpty style. Neo4J added some terms to their license, and those terms are very clear what they mean. In your framing they're now the creators of the license with their extra terms and they can tell you what the intent is.
The legal question is not what the AGPL3 intends. The question is whether you can stick on some extra terms, tell people you have done so, and enforce the terms when part of the AGPL says you can't, when you do have the power to set the terms you want. Is your power to decide your license stronger or weaker than a contradictory term in a contract? This is why it's a complicated legal issue. If they had used the unmodified AGPL, the court case could have been ended in about half an hour (Neo4J trying to enforce terms not in the license, loses). If they had changed a few more lines in the case, it also would have ended in half an hour (PureThink tried to use terms that only apply to previous version's license, loses). It's only because Neo4J screwed up their license so badly that there's any question at all.
It's also "please ignore the fact that 3.5 is a descendent of 3.4, which was AGPL only, and whose licence unambiguously transmits all its conditions to descendent forks."
No, it doesn't. The writer of new code is allowed, if they control the copyright to the codebase, to relicense it. Anyone can fork the old version and use it under the terms of the AGPL, but new code can stop using that code, and the existing code it links to can be relicensed to work with that. That would only be prevented if Neo4J doesn't own all the code to the original version and didn't remove the parts they don't own. An open source license can't transmit its conditions to any code written by someone who once used it, especially when that person deliberately chooses to change it. This is also not what Suhy is arguing. Suhy is arguing that Neo4J's choice to refer to their license as, essentially, "AGPL plus this other stuff" means it can be reset to the AGPL with no other stuff. He has a point, because the license specifically says that you can reset it, but it is unclear, because their additions say you can't. If they hadn't done this, the fact that it used to be aGPL would not prevent them from making subsequent versions something else.
That is why all the open source bait and switch companies can get away with license switches. They own the copyright, usually through CLAs collecting it for all contributed code, and that means they can change the terms. I dislike these switches, so if there were some way to prevent it from happening, I'd like to try it. Hoping that a license will do it for you is going to fail because existing licenses don't and new licenses basically can't, but knowing that at least means we can focus on CLAs and the various mechanisms we can use to prevent it from happening elsewhere.
"From what I understand, the legal precedent would be that the court would consider the software creator's interpretation of what the open source license terms mean instead of the interpretation of the writer of the open source license. That is crazy - who could ever trust any open source license if the software creator who adopted it could interpret the meaning differently - even if the writer of open source license clearly explains the reasoning behind each term in the license?"
The reason it doesn't make sense is that there's a step missing. This is not Neo4J deciding that they want the AGPL to mean something different, so now it does. This is them wanting something different, so they added extra words. The extra words are not at all ambiguous about what they want, but what is less clear is whether they get to add them and whether someone else can remove them. The precedent that is currently applicable says that you can add extra terms when you choose the license to use. Anyone considering doing the same should write their own license, taking whatever pieces they want, but not using the same names. If you do that, you don't end up in this legal morass in the first place, since that has always been legal.
Not quite. The FSF, in that cease and desist letter and in their recent brief to the court told them, correctly in my view, that their use of the AGPL was violating the terms they placed on it. The FSF could have sued them for misusing the name, and I think they would have had a strong case, though not a guaranteed one as the license text was not modified. The additional clause was appended and referenced at the top, which isn't necessarily the same if Neo4J wanted to try arguing that, which they didn't as demonstrated by the fact that they changed the name.
However, this doesn't prove either way whether their inept Frankenstein's license is valid or not, or rather, since it is self-contradictory, which part of it is valid. The FSF's brief to the court intends to support the SFC's brief. It conclusively establishes what the FSF's intent was when they wrote the AGPL, which Neo4J decided to question for some reason I don't know because it should have been obvious to Neo4J what the FSF wanted, because that's why they wanted to change their license away from it. At this point, we have conflicting intents: what the FSF wanted when they wrote the AGPL, and what Neo4J wanted when they wrote their additional clauses. The court has to decide whether Neo4J was able to enforce their intent with the contract they wrote, and so far, they seem to say that the answer is yes. The FSF having a good license violation case is not sufficient to prove that Neo4J's license terms are invalid.
That is stretching things a bit. In a comment in a different thread, I linked to and commented on the text of their license. Right at the top, they state that they are using the AGPL with an additional clause. It wasn't hidden in there.
As for your "verbatim only" point, this seems mistaken and irrelevant. It is irrelevant because that's not at issue anyway. The FSF can sue for that if they like, but they haven't. The issue is whether the clause is applicable to other parts of the license in which it is included, which is not clear because the license they used explicitly states that it does and that it doesn't, so they've stuck themselves in a loop. It wouldn't matter if the FSF had said you could do whatever you wanted with the license; they'd still be in that loop. It is mistaken because the main reason they are in that loop is that they did use it verbatim. They could have fixed the license by modifying or removing a couple sentences, but they didn't, so the license appears in its entirety with no edits. That is, in fact, verbatim in the same way that, if I write an introduction to a book and then include the unedited book, you wouldn't say I had written or edited that book. I agree that they shouldn't have, both for clarity to their users and for not getting themselves into this legal battle, but if you want to make the case based on the terms, they may not support you even if the FSF did choose to sue over it.
As far as I know, the only OSI involvement with this case was their happiness when it was declared that Neo4J's license is not open source. This has earned them a lot of annoyance, because what the court really said was that PureThink could not apply the unmodified AGPL but had to use Neo4J's version, Neo4J's wasn't open source, therefore theirs wasn't either. The OSI expressed happiness about something that was unrelated to whether this license was accepted or not, but because they seemed happy when PureThink was defeated, people assume that the OSI oppose PureThink or did something to engineer the ruling.
What OSI is happy about is a good thing, because it acts against other companies who think they can claim to have open source software when they don't. It is also not harmful to PureThink, because if they win the case, then they will use AGPL and that will be open source.
Some more context on that. They seem to have decided they needed to do exactly what I describe: give their license a new name. This version can be found here. Were this the only version, I'd agree with the court unreservedly. It isn't that clear, but neither is it clear on the other side, when we look at the 2018 version which is at issue.
They say up front that this is not the unmodified AGPL:
The software ("Software") is developed and owned by Neo4j Sweden AB
(referred to in this notice as “Neo4j”) and is subject to the terms
of the GNU AFFERO GENERAL PUBLIC LICENSE Version 3, with the Commons Clause as follows:
The FSF does not want that called the AGPL3, and I don't either. I'm not sure we can make that desire legally binding because it is all the text of the AGPL3, but I disapprove of it. For that matter, I disapprove of the Commons Clause in all its forms, so I'm not an adherent of Neo4j. Still, if I'm analyzing the merits of the court case, it's hard to claim that they weren't explicit when this is right at the top.
One thing that works against Neo4J here is that they failed to change this line:
"This License" refers to version 3 of the GNU Affero General Public
License.
Without being explicit, that would suggest that you can in fact use 7.4 (which refers to "this license") to reset it to the original AGPL minus the Commons Clause. So now we have two contradictory elements of the license, one saying that the clause applies and one saying it doesn't have to. That was clearly not what Neo4J intended, and I think anybody forking knew that, but it means there isn't an obvious answer, even if I might want a specific interpretation.
Neo4J could have easily gotten themselves out of it, but their failure to do so doesn't prove that they're wrong. I'm also not convinced that a court's decision on this will affect the rest of the AGPL or the many places where it is used without modification. This license contradicts itself, whereas the AGPL doesn't. I think it will continue to stand even if Neo4J wins this case.
That's true, but you could argue that they didn't license their work under the AGPL there. They licensed it on their own non-open license where they copy and pasted the text from the AGPL and stuck extra things in. That is not a good way to write a license, but they evidently chose it. If that's what they did, then the term from the AGPL doesn't let you remove anything that wasn't the AGPL, it now allows you to remove any term that wasn't compatible with their modified built-on-AGPL.
This is where I'd be doing something boring like seeing if they claimed their license was the AGPL. If they said it was their new license which just happened to share most of its text with the AGPL, then I don't think that lets you reset the terms. This works in the same way that a license I've used, which was a lot like the MIT license but they added a couple of things I didn't like wasn't MIT, but they didn't say it was, so I couldn't exactly blame them for making their own.
The problem is that it could be used to eliminate other contracts, which could be a problem. Consider an extreme example. I am paying you to write some code into an AGPL-licensed program for me. You've agreed to use that license on the stuff you're developing for me. Once you finish writing it and making it available, I take it and announce that the contract we made which involves me paying you for this is an additional restriction, so under the terms of the AGPL, I am choosing to remove that restriction. Can I do that? This depends on whether the court agrees that this is a restriction on the software, which they might not, but the line is ambiguous enough that that's not guaranteed. With an example as extreme as this, the chances are good that they would throw that out, but with something smaller, they might not.
The bigger question they'd have to answer there is whether a software license can invalidate other, possibly separate contracts. Most of the time, it can't. In contracts where they specify that one document will prevail over another, those documents are two parts of a single contract, for example the permitted use policy of a service and the contract where you say you'll pay them, which you agree to at the same time. Contracts generally don't get to proclaim themselves superior to other contracts, because what would happen if my additional terms say that "if you want to distribute modified versions under a license that isn't the AGPL, you may remove that term"? Which term or terms are you allowed to remove at will?
They donated code to that, but I see no evidence that it was this code, and it seems quite unlikely that it was because Windows already has an NTFS driver. The Partition Manager software that this appears to be part of is a distinct product. If this had been, for example, Paragon's NTFS for Mac OS software, then I'd be more worried that a similar bug could affect Linux, although even then the most sensitive code would likely be OS-specific.
How is pointing out a possible problem equivalent to saying it's too difficult so we should give up? What they suggested was a reason that it might not be worth doing so you would choose not to even though you could, same as mine, not a reason why you could never do it.
That said, I don't think theirs is a very good reason. Undersea cables do get tampered with, but I don't see a reason why many countries would want to cut the ones going to New Zealand. New Zealand isn't in a war zone, nor do its neighbors plan on invading it as far as I know (I'm watching you, Australia). Hotspots for intentional cable cuts are the Baltic, around Taiwan, the South China Sea, and the red sea, all of which are more sensitive than the waters around New Zealand. Nor would damage to those cables cause too many problems for the average New Zealander. Anything on those servers intended for the local market would still be available to people in New Zealand. The people would have reduced or no access would be people in other countries that wanted to run their workloads on those servers. I still think latency will be a problem, but I wouldn't worry much about someone trying to break those cables.
"I reckon the south of the South Island would be a great spot for data centers for cloud hosting - cool weather and plenty of water for further cooling, electricity (at least if they knock that stupid aluminium smelter at Tiwai Point on the head), a timezone opposite that of Europe, no wars likely in the vicinity, etc etc."
For most cloud datacenter purposes, there are some major downsides. They have some datacenters in NZ already for serving the local market, but for serving any other market, you have latency and network contention problems. Australia is the cheapest place to use NZ datacenters, and they probably could, but they have many there already so they may not need to. Any other continent isn't going to want to use them for many purposes. Compare to European datacenters, which often have similar climatic conditions and reliable, if not as green, power, and are also close to their users and much larger oceanic cable systems.
Your suggested datacenters might still be viable if they were specifically aimed at the AI-style use case, namely workloads that aren't time-sensitive but use tons of processing and thus power. It might work, but that may not be enough given how many other places that can work in. Especially if building one relies on a smelter shutting down, because they wouldn't want to build unless they know it's going to happen if the consequences of it being delayed is that their datacenter operations are also delayed.
This is valid, the typical trusting trust problem. However, I think the more concerning one is the Underhanded C problem. There is a lot of code that nobody is reading, and there's code that people aren't successfully reading. Not all vulnerabilities are obvious, whether that hidden-ness is deliberate or accidental. If you have the ability to read code, you almost certainly know this from experience, because we've all written bugs that should be simple to fix but you can't see the problem for the life of you.
Just because they don't build it doesn't mean there's a conspiracy not to let the market decide. If they thought people would buy a lot of those, they'd make them. They probably aren't because they don't think people will want them, and if that's what they are thinking, I understand why.
Why would someone want that? Other than being easy to hold, is there any advantage at all? What interfaces are going to adapt well to a landscape portion and a portrait one, but not a full rectangle? You could spin it around and put the keyboard on the landscape section and a message list on the portrait one, and then you'd have more room for both, or you could have two apps open a la Surface Duo, but otherwise, it seems gimmicky and not very easy to convince people to buy for the increased price that any hinged, multi-screen device tends to cost.
In my opinion, it is overused, but it is possibly correctly used here. This does seem to meet the definition: changes intended on getting more money from the users, in this case by selling their data, by making the thing they use worse. Where it is overused in my opinion is when people use it for any change they don't like even when the change is subjective or just unrelated to funding, for example when some designer changes the interface again. That doesn't qualify because that wasn't done to get money out of you or something else; the designer just disagrees with the users about whether that change was a good thing.
In the product documentation, you need to document the options so that there's enough information that you can make that shorter page. True, that documentation and the checklist you're making are probably not written by the same person, but it is still important to have them both. I can't count the number of configuration pages where there is an option that I can configure but I have no clue what it does because it just has "TRS, default setting 0", and doesn't expand TRS or explain what it does. The more professional the equipment, the more likely there's a manual which explains it somewhere, but there is a lot out there without such a thing.
If I'm supposed to be a human computer, simply setting anything the way that my knowledgeable colleague said, this is not a problem. In that situation, there is no need to train any other engineers either, since we just need to have existing engineers write up some one-page processes and hand them to people who need to have no skills or interest in gaining them. There are quite a few people I know who don't know or want to know about computers but can be trusted to complete a completely rigid set of instructions about where to click and which box to put which value in. That is not what network engineering requires. The reason we need people with knowledge is that these things are complicated, and having the skills doesn't help unless they have enough information about what the systems do that they can figure out when the defaults or the things written on the previous configuration need to be changed, how to test that their changes worked, how to test that their changes didn't break something else, how to reverse them if they did fail, and how to diagnose a new problem that they haven't seen before. At most only one of them, number 2 on that list, can be in the one-page checklist, and in most of the ones I've seen, that one isn't on it either.
The one page of notes works fine once you've done it several times. The longer documentation is necessary for every other situation, such as the first time you're doing it or the time you ask someone else to do it. You need it, for instance, when Install S:\Apps\blah\driver\timmy asks a question, emits an error code, or doesn't work because this is a Windows on ARM machine. Most of those won't happen, and the ones that do you've seen before, but the documentation is there to handle that kind of case.
It's the same problem that we often get in software documentation. Man pages, for example, are famous for using lines like "-D: detail mode". Great, I know how to turn that on. Or maybe that's on by default and this is for a different case. What does it do? What is the alternative? And that in programs that often have twenty different default configurations, such as that detail mode is enabled by default, goes into extra detail mode if you specify it twice, disabled if piping to a file, disabled if the number of targets is high enough, and on and on. This holds for other types of documentation as well. People leave out things that seem obvious, and when you give it to someone else, they can't do the task properly until they've figured it out, or worse, they still can't but it isn't sufficiently unclear that they know it, so they do what the documentation says and seem confused when the computer fails because nobody thought to update the documentation that you don't install wotsit by executing wotsit_setup.exe, even though that will offer to install wotsit. You run the batch file in there which does some configuring and calls the installer with some command line parameters. Everyone has installed wotsit, so we don't need to update that, the line just reminds you that's the next step. When the trainee messes up, we'll blame them instead of the doc they were following.
You should probably encourage them into whatever career seems to match their skills and interests, and IT isn't a terrible one. A lot of stupid managers are going to fire people and outsource them or try to replace them with AI. A lot of managers are going to hire more to deal with the disaster caused by the first one. I'm not sure there are many or any jobs where you can avoid things like that that don't come with equally strong negatives. Unless you know of a career where job security is universal and easy, I'd still recommend IT to someone who was good at it and enjoyed it.
I am a programmer, and most of the job descriptions are very vague on what they want people to do and what experience is actually useful. I did recently see a job description that went so far the other way, asking for someone who had worked in a very specific area. Essentially, they wanted someone who had already written exactly the program that they wanted and could, I guess, just come over there and write it again from memory. Points to the job description for making it very clear what they wanted, but they should probably have considered that their task was something that quite a few embedded Linux people could manage and they might not have as much success trying to find someone who had already done exactly the same thing.
I'm not sure that's true. To me, the article reads as the much more boring statement "You might find that you like working or get bored when not working, so you'll keep doing it". Which, for some people, is true, but they will be able to figure that out for themselves and hopefully will be able to do whatever thing they find most enjoyable in their older years. I have a lot of time to go before I can consider that, but I expect that I would get bored if not doing some of the things that my job acts as an outlet for. Maybe that will make me stay in the workforce longer even if I could be financially independent, but maybe it means I'll spend more time doing that kind of thing as a volunteer for charities, something I already enjoy doing sometimes, and maybe I'll find that it gets old after a while and I'd be happier not doing it after all. That probably doesn't apply to plenty of people, who continue working for financial reasons and would be happier doing something else.
They do, but "case" in this sentence means only the plastic shell so you're not using the bear board. It doesn't let you do anything else with the board, for example attaching a fan so you can run hot more of the time or having any of the other things you tend to find in a desktop. Not that they need one. I wouldn't really expect their desktop to use the same mainboards as their laptop; while it would be nice if they could manage it, those are designed quite differently. A 12-inch laptop and 13-inch one, especially when the 12-inch model exists to have a touchscreen and 360-degree hinge could use the same boards. As I said, I'm pretty certain that they don't or they would have said so, but this would be a disappointment to me because the potential is too obvious and few downsides would exist.
One of the things that made me choose Framework when I bought a laptop was that they intended to keep the same form factor, and they have proven that by continuing to release mainboards. I am less confident that they will have a similar amount of demand for the other model, which means they may have to choose which one will continue to get upgrades and which one gets dropped. If they used the same mainboards, they'd just have to keep making the chassis for the smaller model, making it easier to have multiple niche devices, and they would be able to use economies of scale for the mainboards which could be used in several types of devices. If I'm right, I have a feeling I'll be lucky and the 13-inch laptop I have will be the one that lasts.
The only model they've done it with is the 13-inch laptop, but you have a few years of mainboard upgrades you can use as evidence. They're not cheap, but they are substantially cheaper than a full laptop. If you want a newer processor, upgrading them is quite easy and you still save a lot over the full laptop. For example, to put a Ryzen AI 5 340 in an existing laptop costs £/$449/€529 whereas a new laptop with it in it starts at $/£1099/€1309. Note that US prices do not include taxes whereas UK and EU prices have VAT included, thus them being higher.
Could you link some? I have failed to find anything detailed. I have found a lot of articles that describe it, including confirming that it's using the same expansion modules that the other machines do, but they are much less clear about everything else. I assume RAM and storage are replaceable because it would be crazy if they weren't, the desktop notwithstanding, but none of the articles even mention this.
It seems unlikely to the extreme, but I would have hoped that they could build this around the same mainboards that are used in the 13-inch laptop. I expect that this will use a mainboard with a CPU with a lower TDP because the battery is smaller, but that would have been an advantage for the laptop users who could opt for something cheaper and lower power, and convertible users could update to other boards that could operate with the smaller battery. For example, you could probably run the RISC-V board on the smaller battery if you wanted to. My primary reason for wanting this is that, if they have one standard mainboard, it is easier for them to keep making new ones and for users of older devices to replace them. It also makes it more likely that someone else might make a compatible mainboard. Now that they have four different models, none of which have board compatibility with any others, what happens if they decide to stop making one? I understand why the 16-inch laptop benefited from a larger board, but I'm not sure whether there will be as many benefits to the convertible.
Your suggested alternative? Sadly, I have neither an M4 Pro nor a Ryzen AI Max 395+* to run software on, so I needed a benchmark that includes enough candidates and samples to provide me with any numbers. Passmark has both. Most other benchmarks I'm aware of either don't have as many samples, don't work on as many operating systems, are operating system-specific meaning a Windows or Linux Ryzen measurement can't be compared to Mac OS M4 measurements, or simply don't have good numbers, apart from a single user-provided number, available to me. When citing your suggestion, I'd also appreciate any reasons you have for thinking the benchmark is more accurate.
* After typing the AMD processor name a few times now, it strikes me how much I don't like their new naming conventions. They seem to have taken a hybrid approach between Intel's and Apple's naming, and I don't think it helps.
I agree with you that it's not very impressive, but don't go overboard in your quest to prove it. They didn't have an option to use replaceable RAM with the CPU they used, but that might have been an indication that they should consider using a different CPU. Unlike their laptops, there is not any repairability benefit to their desktop.
But you've decided to go compare it to a Mac Mini, so let's do that.
"A Mac Mini with M4 Pro is going to handily beat that, and cost less too. Quite a trick for them to be underpriced by Apple lol"
The Mac Mini with M4 Pro starts at $1,399 (I'm using dollars to avoid including tax in the comparison). The Framework Desktop starts at $1,099. That cheapest Framework has 32 GB of RAM. The cheapest Mac Mini has 24 GB. Not looking great for your comparison. If we want identical amounts of RAM, we can do that. For $1,599, you can get a Framework Desktop with 64 GB of RAM. To get 64 GB in a Mac Mini, the price jumps to $1,999. Not cheaper after all. But, of course, there's more to a computer than RAM. Let's compare CPUs. The 12-core M4 Pro receives Passmark benchmarks of 4623/33153. The CPUs used in the Framework haven't been benchmarked yet, but the one in the comparison is a 16-core CPU with a 55 W TDP. AMD does have one of those that has benchmarks: last year's AMD Ryzen 9 7945HX (4062/54826). The Mac's storage is significantly more expensive and proprietary, so to have more than the default 512 GB, you'll be adding a lot more to that price (a 2 TB SSD does not cost $600 elsewhere).
Your price comparison is wrong on all levels.
Out of curiosity, why would you prefer that? There are several problems with the model that make it less interesting to me. Compared to the Framework, the Pi 5 is a lot slower. Four A76s is not very much in comparison to modern CPUs, and it maxes out at 8 GB of RAM (there are 16 GB full Pi boards, but not compute modules that this laptop uses). There are some tasks I want to run on a laptop that use more.
Perhaps my biggest problem is power management. The Raspberry Pi uses a lot of power to deliver the performance it does, and it doesn't have lower power modes, or at least not support for them in software. This means that, whenever I connect one to a battery, it takes a very big battery and I have to perform a full shutdown any time I want to leave it for a while and come back with some charge still in the battery. That makes a laptop based on it much less interesting.
I kind of agree with you, in the sense that, if I bought this, I wouldn't expect that I'd increase the RAM and I wouldn't expect it to break, so it not being replaceable wouldn't affect me very much. However, since this is Framework, the comparison is inevitable and fair. I don't think Framework will have a monopoly on these AMD chips. They will likely appear on other computers that may not be any less repairable, and other than having two replaceable front ports, it's otherwise not much different than other boxes would be. A replaceable SSD is the bare minimum, and one I'd expect in every desktop that didn't have an Apple logo on it.
It's actually a pretty nice small computer with good performance, as is the Framework laptop, but when we compare the two, the laptop is far more than that where the desktop's benefits mostly end there. This is partially Framework doing so well that their next attempt doesn't look very revolutionary, but knowing their customers, they should expect that soldered RAM was going to get brought up about two thousand times, sometimes just because it's something they fought against with the laptop and sometimes because there are people unlike me who do anticipate wanting to increase or replace the RAM who will be disappointed that they can't.
Not contact discovery, but initial account registration. You enter your phone number. They verify your phone number. They have your number at that time (and they keep it). If it starts with +46, they can reject the registration. Contact discovery pseudonymizes numbers, but since there is no need to reject numbers at that stage, that is irrelevant.
China didn't do that to Android. Chinese companies took the open source code for AOSP and used it, and they weren't the only ones. It is much harder to do that to something that isn't open source, especially when, if you do it as an element in a trade war, the country where it is based can retaliate against you by taking, and possibly publishing, any important software a company operating there has.
In addition, your example doesn't need that. Any cloud provider who wants can use AWS-compatible APIs for almost everything. The number of places that have S3-compatible storage systems should make this clear. The reason they haven't done it for everything else is that S3 is a simple API and other services aren't. You can reimplement all the APIs that exist for AWS Lambda, but nobody wants to, especially as it makes it easier for their customers to leave them as well because why would they ever write for the private API rather than the standard, easily movable one?
Or, perhaps, for the same reason that these major cloud and software providers are major everywhere else: they have a bunch of products that are easy to get in to and hard to get out of. It is easy to decide you need a device management system, you've got Windows machines, you'll use Microsoft's software. Now that you're doing it, changing to anything else runs into the problems that the alternatives have fewer features and you'll be spending a lot of time and money to get to the same place you are now, so it gets put off. It's easy to decide you need email, calendars, and shared documents, so you'll sign on with Google Workspace. It's hard to get all your data out of that and transferred to somewhere else. It's hard to find somewhere else that could take all that data if you did transfer it, meaning you're either switching to another company that's quite similar or you have to set up several replacement services instead of one.
You are right about most of these, and I don't think the risk is as high as described. However, the risk would be a lot lower if the EU bothered to enforce any of those things. If GDPR were enforced as written, it would be incredibly scary to all the large companies with massive bank accounts in Ireland that could easily be fined for what they do. When it was passed, they did seem to fear that someone would enforce it, hence all the scrambling to update terms of service documents and stop certain programs. But then nobody ever did anything with it and those programs started back up again. The DMA did get used as a big stick a couple times against Apple, and Apple started to comply, but then someone got distracted, Apple noticed, Apple halfheartedly finished a couple things, breaking them so they wouldn't have much effect, and nobody did anything about them. The many powerful incentives available will do no good if companies assume they'll never be used, and it makes it harder to change their mind and use them once because the numerous examples of everyone else who gets away with violating them can be used to delay or derail the process.
DNS is distributed. European DNS requests rarely go to DNS servers in the US unless it's specifically for a US entity. If the attack you describe just happened to things hosted there, it would have little effect. Even if it extends to any DNS server operated by a US company, that would be more severe because Google and CloudFlare's resolvers are the most often used, but there are lots of DNS resolvers hosted in the EU by EU companies, none of which would have done this. Root servers are operating in many countries. The protocols in use are standard, so at worst, people who used 8.8.8.8 would have to enter a new IP address. Consumer ISP users might not notice, having always used their ISP resolver.
Cloud providers are much more concentrated and are much harder to substitute. However, many of them operate from EU-based subsidiaries, if not EU-based parent corporations to avoid paying as much tax to the US. There is a lot that EU governments could do to prevent damage being done, or at least to make the companies suffer if they complied, and the companies are smart enough to know the risk to their cash flow. I expect that they would resist things likely to antagonize the countries in which their valuable servers and customers are, even if they try to hide that they are doing so.
That would depend on your definition for "wet", but I think you'd find it hard to prove. Wet tends to be used to describe things that have a lot of liquids in them, and that would make water one of the wettest things around, along with other liquids with no solids at all. Something doesn't have to be a liquid to be wet, if for example a solid got covered in a liquid, but that doesn't make liquids non-wet.
That was the point. It's easy for people to convince themselves that there is some other problem when the alternative is that they've made a bad decision. It's common to ascribe any bad decision, whether or not it was obvious beforehand, as stupidity. People don't want to feel stupid or to have others view them as stupid, so in defense, they find reasons why that's definitely not what is going on.
I've seen lots of people do it, for example a person who doubled down on a massively expensive contract they could have cancelled at will because doing so would suggest they didn't pick right the first time. I've also done it myself. This is why, while I'm not concerned about the comments made in the original post of this thread, I'm concerned about people trying to identify the lazy before the tool can improve productivity.
If it actually worked, then at least some people would be expecting more performance out of people and penalizing lazy ones who didn't do it. It has worked before. When computers sped up certain operations, most workers, either by choice or by management started doing more things. The problem is that this might also happen now, when the tools don't actually improve productivity but some have come to believe that they do. If someone has been convinced to buy expensive LLMs, they will probably conclude that they must improve productivity, otherwise they wouldn't have bought them, and that if they're not seeing productivity increases, it must be because someone is being lazy.
CISA has been covered in this paper quite a lot. I think most people working in security have heard of it and know what it is, for the same reason that I, a non-UK resident working in security, am fully aware of what NCSC* is. Maybe that still should have been covered in the article, but it is far from the first time it has appeared here.
* National Cyber Security Centre, you could call it the UK equivalent of CISA in the US. NCSC is part of GCHQ. I know what that is too.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
