Posts by doublelayer 10368 publicly visible posts • joined 22 Feb 2018
At the point where you need that, you might as well skip that and communicate the error straight to tech support automatically and lock the application until tech support clears it (be sure to have a report key in case more than one comes through at once). In both cases, it's a lot more than most problems deserve.
I doubt it. In my experience, yelling deadens most of the reaction to real problems and stupid solutions don't really help either. If someone asks for a blob applied to their screen, I'd probably ask why and try to find a better solution. If they don't put up with that but are satisfied with that simple fix, then I'm less likely to consider if they had a good point about interfaces, especially if the "asks for" could be better described as "screamed at me for not having already done". That's regardless of whether the problem was real. While that's not necessarily a good thing because it would be nice if every potential problem got a full review, I, and a lot of others I know, have limited time to do that and therefore use rough but fast heuristics to decide whether to bother thinking further or just make the user happy and go back to work.
So what's the answer instead? Put the line at the top? How would that make any difference when the screen is small enough that the user can see the whole thing. Especially when, as in many cases, the bottom line is already used for status and this is a status update. Instead of making a new type of window, you continue to place the information in the same place, meaning any user who receives training and understands it knows where to look for the information about what's happening. Consistency can be helpful to users as well.
While I kind of agree about IT visiting, that's based on an assumption that any building with users on terminals probably had IT on site. If it was a distributed thing with a user at a facility with no IT staff on site, we're now talking about a much longer travel to have someone physically show up for a minor problem.
But the tape thing is different. I don't know what the procedure was for loading one and whether the user might have had to ask for it. Maybe there was someone who should have loaded that earlier. However, even if it was completely automated except for a human loader, there would still inevitably be at least a couple minutes latency for any tape to be loaded and the user would still see that screen, just for less time. They would still have had the call with the helpdesk, it would just have abruptly ended when the user hopefully said that it all came back to normal. Either way, when the user faced an expected part of the interface and didn't understand it, it was their inaccurate description of the situation that caused all of their problem.
I'd adjust it a bit. In my experience, it's not the people who can't read, as in don't understand the message. They usually ask for help and listen. It's the people who can read but don't. A lot of messages that get ignored are things that the user can understand if they read them, and even if they don't, it is something they can contact a person about and read clearly so that person can help. A lot of people do that. Those who don't usually don't out of choice rather than ability.
I had the opposite problem. A charity I sometimes volunteer for wanted a copy of something that was being maintained for them by another company. That company provided them with temporary FTP credentials. So far, I wasn't involved other than recommending an FTP client because I hadn't set up that service. But when they consistently failed to figure out how to use the FTP client, even with the assistance of their providers' helpdesk, that's when I was called in.
The people at the charity were using the FTP client correctly. They kept getting errors and new sets of single-use credentials, none of which solved the problem because the people providing them evidently never thought to consider that their FTP ports are normally firewalled off with an allowlist and, as far as I know, never collected any IP addresses to allow through. Every connection would time out before the credentials were tried because only the SYN packet ever got sent. I don't know why their support system wasn't equipped to add things to their firewall when they were to generate an infinite number of temporary passwords, but it took escalation to what they called L3 support before they found someone who understood my email which boiled down to "This is the IP address. This is a log of no TCP connection. This is a log of a successful connection to the port the application runs on. Something is wrong with only the FTP server. Might this possibly be that this address is not allowed through your firewall?". I wanted to but did not ask "What address did you think would have worked here since you never asked anyone for one to allow".
That's one approach, and nothing's very wrong with that, but another perfectly valid approach is to have a flat top surface if it fits your design but don't make it in such a way that it causes problems. Put the power button, reset button, ports, and everything else on some other side and leave the top blank or with something decorative on it. That way, it can be flat and it still can't be misused. Designers should always start with how their equipment will be used and can then be creative within that envelope.
It still should be something that never happens, since the user was not asked to understand or even read the message, just to recognize that some things on the screen is not the same as the screen being completely blank. Sadly, it's also very common. I have a few people who will report problems to me but cannot understand that, if there is an error message, I want to hear A) that there was one and B) what it said, and if there was not an error message, I want to hear what was attempted, what normally happens, and what happened differently this time. I don't know why they have not learned that, when they tell me that "The server doesn't let me work", the first thing I'm going to ask is what it said (okay, what I'm first going to ask is what they're calling a server today, but once we've established the thing they're trying to work with, looking for the error message is the first step after that).
Social media companies oppose the law because they don't want to be regulated. I oppose it, not because I care for any of the social media (I have no accounts on any of the services listed though I've occasionally considered registering for a Reddit account but then not bothered) because I don't like having to hand identity documents to data thieves and take video of myself to use the internet.
We can easily disagree if you think that your interest in keeping your children off sites you oppose is more important than the privacy of any adults using the service and I think that it's not worth giving up privacy and access because it makes being a parent easier. Part of the reason I don't find the view I think you're expressing very convincing is that there are many things parents can already do to keep their children off social media and very few parents, including everyone I've heard calling for this, seem to be trying anything. The few I know who do have mostly managed to keep their children from it, and one effective technique involves no technical measures whatsoever but just explaining why it is not a good idea. Perhaps that experience colors my view of laws like this because if they clearly don't care to do anything on their own, why should I give up things to mostly not solve the problem. Maybe you have taken some steps to protect your children, in which case I'm still not convinced because the chances are that whatever measures you've used are more effective than the weak things this law puts in place. The laws seem to have just enough effect to be able to claim that something was done while coming with significant privacy harms and the people demanding it don't appear to take much responsibility for themselves. This is not a convincing combination.
Here's my bid. Find out what social media does which causes the biggest problems and pass laws against those that restrict the social media companies rather than the users. For example, if one risk is the collection of user data which we'd rather not do to children, then we might pass a privacy law, kind of like GDPR but one that actually gets enforced, which would protect everybody instead of collecting identification for every user which the less scrupulous companies, so probably all of them, can use for their advantage. If the problem is malicious users, then penalize companies for not acting on reports of malicious activity, and if you don't think their mechanisms for reporting that activity are sufficient, mandate that more be added. In general, clearly define the problem and try to solve it.
And while you're considering that bid, can I add another aspect to your criteria? In addition to having regulations that are more effective, one other thing we might want is to make the regulation less harmful. I can make many regulations extremely effective if we don't count any damage that regulation causes. Australia's social media ban and, to a greater extent, things like the UK's OSA which followed suit, have lots of negative side effects on privacy and access.
Fortunately for the rest of us, that's not how courts work. Even if they fail, they will not be fined for raising a completely normal constitutional challenge. And it's far less stupid than you think or phrased. The constitutional right has been upheld by Australia's courts many times, and never in the text or in their opinions did they decide that children don't have that right. They could modify their ruling to account for that, but that would be a substantial change. I agree with you that the second argument about anonymous accounts doesn't seem to have any effect on the law; sure, it might kind of work as an argument that this law is stupid, but courts can't strike down laws for being stupid, only for contradicting other things, so I expect that part to go nowhere.
That is not parental gatekeeping. It is governmental gatekeeping. If a parent thinks something is fine, can they let their child do it legally? No. If a parent thinks a different site is bad, can they add it to the denied list? No. It is not giving any parents more power. It is the government making blanket parenting decisions, whether you like those decisions or not.
Not if you think the law as written is illegal. If you do, you can make that case, and if the courts agree with you, you win and the law stops existing. Are you unaware that laws can sometimes be struck down? In this case, their first argument is an easily understood constitutional complaint, if not one that has an obvious answer. If you tried to pass a law that had a higher age limit, it would almost certainly be struck down as a violation of the Australian Constitution's guaranteed rights, so the question for the courts to decide is whether it is compatible to deny those rights to children. It might decide that it is because those children cannot vote, but it is far from the obvious result you claim. Countries where you cannot do that have a name: dictatorships. Fortunately, Australia has the rule of law and must properly handle challenges like this, whatever the answer ends up being.
Why do you think that's new? Why do you think that's bad? It is neither. If a country passes a law that is not compatible with other laws, that's one of the tools, and in practice pretty much the only tool, to do anything about it including finding out what the answer is. That's the entire point of legal and constitutional courts, as opposed to criminal and civil courts. While countries rarely have explicitly designated courts only for that purpose, most of the higher appellate courts spend most of their time on exactly these problems and have been doing so for centuries, pretty much as soon as the rule of law took over from royal decree.
You are correct that that would be better. The problem is that it would also be more expensive and take longer. It's almost always easier and cheaper in the short term to write code that does the process you do now. Making one that can handle changes requires thinking ahead about what changes might look like to make sure every part related to those is implemented in a nicely expandable way. Some of those aren't too hard, but to make it fully generic takes quite a lot of brainstorming possible places where someone might need to insert a change and ways to make sure they can if they want to. That' just if it's acceptable to have programmers whose entire job is making those changes and just trying to make it easier. If you also want users to be able to implement those without needing to reprogram the component, then you have a much harder task because you have to implement lots of interfaces to modify the structure and flow of the software and deal with compatibility issues between the different components.
That kind of thing is also hard to explain and sell to the people who pay for it. From their perspective, either way they get software that looks and does the same thing. To some extent, the people writing it can ask them what changes they are planning and those can be the first types of changes they design for, but most times I've asked about this kind of thing, the person with the requirements doesn't anticipate making many changes, wants their code quickly and doesn't take kindly to the months of additional preparation, and therefore chooses an approach where that doesn't happen.
I think an important part of your post is "accepting less functionality from the new mega-system", which doesn't necessarily have to be bad. Done well, a rewrite gives you the opportunity to decide whether you really need everything you built and, if you decide that you don't, to redesign processes around the system you'll have. I find that it's easier to do that kind of thing during design than when something mostly already exists and anything else is being implemented as a bolt-on component. Of course, their costs suggest that they might not have been doing a lot of that and from my experience of Workday, and to be fair to Workday pretty much everything even slightly like it, my hopes are not very high that it would be great.
That version 2 has broken doesn't prove that version 1 was fit. In fact, without any other evidence, I'd consider this massive bill a suggestion that what they had before probably wasn't good enough, because as the project continued on with worse and worse outcomes, the temptation to abandon it and just use what we have would grow. It's worth considering that the people building these are likely different since version 1 was written in the 1990s. One of the reasons the system I described was harder to modify is that the people who wrote the C++ original had left and their replacements knew the language but not every internal structure in the program which had not been documented. Any institution can mess up a complicated system two times in a row, and some of them can mess it up every time they try.
Sure, maybe that's what that translates to. However, maybe it translates somewhat differently, because I've also seen deployments that could be described that way. The way those worked, the ancient application from the 1990s needed to be manually tweaked for every change in input data because that input data was defined as a sprawling C++ object rather than anything that a non-programmer user could modify themselves. As processes changed more frequently, that meant more work for the people who maintained it and now had to spend most of their time operating it. It had serious efficiency problems which couldn't be fixed both because there wasn't much documentation of everything inside it and because the people who could give it a try were busy running it over and over every time someone who wanted output needed some changes which required the programmer to modify the source, so they had no time to reimplement big components. One procedure was so tricky to automate within the software that nobody did and, if you wanted the results which were needed at least twice a year, there were two different ways to do it: way 1 which involved a bunch of people in a room manually moving pieces of paper around and way number 2 which involved a separate Excel spreadsheet with macros that routinely took eight hours to complete.
How do you know they didn't have those? You don't have evidence to say that their old code worked any more than I can use my anecdote to prove that it was as fragile as what I have witnessed. Keep in mind that universities change a lot and software that handles them properly would ideally be implemented so generically that it's easy for the software to handle when departments are created or destroyed, when the criteria for graduation change, or about a dozen less common* but more drastic administrative changes, but in practice, most software is not written that way because doing that takes a lot longer than writing software that works well with the system we run today and we can always patch it when things change later.
* The examples I posited are just things that happened at my university while I was a student. Sometimes, things get a lot more crazy and difficult to handle. I doubt Workday will do a lot better, but I wouldn't have bet on the previous mechanisms.
Presumably the other part of your recommendation is ""don't be price-sensitive"". The point of most of the aggregators is to get lots of prices for similar things so you can decide whether flying an hour earlier of a different airline, possibly not one you've used a lot, is worth a lower fee. In my experience, the next step is to go to that airline again and see if you can get an even better fee from them directly, which you often can, but if you always go to your standby airline, you'll always get a flight but you may not be paying a low amount. Not only are there many people for whom cost is important, there are some for whom it's so critical that they can't travel without optimizing. The alternative is just to have all the airlines websites open and try to look up the options on every one of them simultaneously, navigating each site's method of showing you the flights that it would be most advantageous for them that you buy.
Mostly, the battery consumption with those turned on is negligible. Bluetooth uses more active scanning, so it would technically decrease your battery life but usually it's been optimized so much by companies that specialize in Bluetooth chips that the decrease is not noticeable. That is different when a device is connected and using the connection which definitely does drain battery somewhat faster, especially when doing things like audio which require constant high-bandwidth transmission, but if it's just sitting there looking for a device announcing itself, it's very low. NFC is mostly passive until activated by proximity, so that would be even harder to notice. If you need to eek out a couple more minutes from a charge, then turning them off might get you that, but if you expect hours of difference, you won't get it.
"No, the onus is on the employer."
The employer will only be an employer if they think the perspective employee is going to be able to do the job. If they think the employee cannot or will not have the infrastructure needed to do the job, then they won't be the employer and have no onus. If I was the interviewer, I wouldn't consider someone having a bad connection as an indication that the employee isn't good enough, but before being willing to hire them, I'd need to know how we could get them a suitable one. And if we can't manage to do the interview for me to decide they're good enough except for the bad internet, then that's not going to go their way.
Your assumption of companies' willingness to hire someone with an inadequate internet connection is pure guesswork on your part. It all depends on what that lack of connection does to the quality of the work, including meetings and anything else that requires data transfer. Whether the better connection is claimed through the company or just included in the salary, they're going to need one to do the job.
I would have to ask them if they have another option. Perhaps that is the best service they have because the local ISP won't build anything better. If that's the case, then although I sympathize, unless they have an alternative planned or are going to move, I expect it's going to make them incapable of doing the remote job from the remote place they've chosen.
As the candidate, I'd have to find a better place to do the interview from at the least because rescheduling it repeatedly isn't going to show me in a good light. I can easily conceive of this being caused by understandable circumstances. For example, perhaps the cable delivering service was cut and, although the ISP told me it'd be fixed by Tuesday so I rescheduled the interview for Wednesday, it's late on Tuesday and the cable is still broken. At that point, I would be trying first to find another place I could be on Wednesday to do the interview. It doesn't automatically mean the candidate's in an unsuitable position, but that the possibility they are is so severe that reassurance is likely needed.
Sometimes, they are pointless, but sometimes, the benefit is speed and context switches. We can discuss one idea between us and collect each other's opinions more quickly without writing detailed written proposals every time which makes it safe to suggest things that aren't fully fleshed out, and that sometimes turns out to be useful because something you would have rejected if you had to formally specify and request it might turn out to be a good idea after all when combined with other things other people knew. By "context switching", I mean that it takes much less time to switch between me telling you my idea and you telling me your idea, hopefully for the same thing, whereas writing things back and forth can take much longer as we either wait for each other to have free time to respond to the message or, in the case of a synchronous chat, wait for the other person to write and edit their response. I'm with David Mitchell (video) on this.
As I understand their obsession with the south pole, one explanation for why there's not an edge to fall off if the world is flat is that Antarctica is a big ice wall that keeps the oceans from flowing off the edge and onto the floor (or whatever is below the flat which they never seem to have thought about).
I don't know who came up with that theory, and if you try to work anything out geographically, it breaks down. It would put the north pole at the center of the planet, and I have yet to hear an explanation for why the center is cold, halfway from the center to the edge is warm, and the edge is also cold. Maybe there's a ring-shaped heater suspended over it somehow. The reason for the north pole being at the center and the south pole being the edge is because they argue that planes never fly over the south pole which proves that airlines are covering up the flatness. I've also never heard a theory for why anyone is advantaged by covering this up. Those times I've talked to flat earth people, both of them, I've always secretly suspected that nobody, or at least nobody I've met, actually believes it and they just find it fun to play-act that they do.
I don't know about that. As soon as they started trying, RAM makers could increase production to their capacity and undercut them. Those companies have already been paid or entered into contracts, so they don't have an incentive not to. I'm not sure the market is complex enough for OpenAI to successfully set up a middleman position in it.
I don't think they are entirely "humanities focused". Their objections include lots of problems when using them in scientific or engineering areas, and in fact most of the problems they name are worse in those areas. If you're asking for some poetry, a little variation from the same prompt is not going to hurt and may help a little. If you're trying to use this tool to solve a problem where answers are right or wrong, variation makes it much worse.
I'm hoping that you successfully use this as a tool. Maybe you do. Unfortunately, I know many people who say they can and they definitely do, a tool that solves their problem very quickly if the problem is that they have tasks to do and solving the problem consists of being able to lie that those tasks are now complete. Unfortunately, most people I know who like to use AI have quality problems and some of them make those my problem by failing to care enough about the usefulness of what they produce. You can get lots of summaries that occasionally include completely wrong information. You can write lots of software that occasionally fails to even compile. Perhaps it is sometimes faster to correct the inaccuracies than to generate the whole thing from scratch, but I unfortunately have to deal more often with people who decide that it's always faster not to correct the inaccuracies at all.
They probably got quite a lot out of OpenAI as well, though the terms other than the investment, and most of the important ones about that part too, are not disclosed in things I have found. There's a benefit for OpenAI, and not just the one that when Disney goes after all their competition, they'll be insulated. Disney has lots of money and lots of lawyers experienced at punishing people with copyright, so AI companies don't want Disney for an enemy, especially if they teamed up with someone else.
Meanwhile, most of the Disney-related output is probably not something Disney actually cares too much about. There's plenty of art depicting Disney characters, and while they are more vicious than some others, they mostly ignore it because they don't have much of a choice and aren't suffering as a result. I think Disney probably came out ahead from this negotiation and that OpenAI probably isn't very disappointed either.
Both parts of that are words for substantial amounts of praise. Gush is a common term in English, whereas agrada sounds like it was either taken from one of a few romance languages where it's a word meaning the same thing or as part of one of a few English words that come from the same Latin root such as gratify, congratulate, or ingratiate. So I think you could translate that as "I read an intensely self-congratulatory thing from Google". I'm quite certain that's the intent from the gush part, so if they meant something else by the "agrada", they can correct this.
If we're going to be pedantic, and you started it, then those integrateds don't mean the same thing. The original integrated meant that the development tools were all together, integrated with one another. The second one means that those tools, still integrated with each other, are now integrated with a code guesser too.
That's neither small nor obvious. The old version involved copying and pasting code into and out of models, and it was a lot worse if you wanted to play roulette with your code generation. How to keep all of that code in the context window was tricky. Now the software is theoretically able to manage it for you. I doubt it does it well, but that's something that was quite a bit harder with standalone models. Other coding models managed it with IDE plugins which had similar goals, although depending on how much work Antigravity did, it could easily exceed those in feature set, and if I had to guess based on the amount of destruction it can cause, I think that it is likely they have managed a larger integration than their competition.
The more people there are who understand this, the more it happens, and yet even if managers and PMs don't understand it, there is a certain amount of coverage that programmers will do all on their own. I know that, if I don't make this work with certain error cases, they're going to happen and I'm going to have to fix it and I'm going to be yelled at for why it broke in the first place, so I might as well make it work now. If the PM who didn't understand this complains about me doing that, it's probably easier for me to explain, possibly dishonestly*, that this is necessary to keep it from blowing up than to try to do that after they have an error they are blaming on me.
* I fortunately have mostly had managers who understood what I was talking about so I've rarely had to. I will admit that I have, at least once, lied to people that something I was fixing was done to prevent serious consequences even though, in practice, we might have avoided the edge case altogether and it wouldn't have been terrible if we hit it, just because I didn't want to live in a world where the code was guaranteed to fail if we did. In that situation, we did end up hitting that edge case (from logged data), so I count it as having saved at least a day and some user complaints, but that was not guaranteed.
Some definitions and translations you may find useful:
Contoso example: A fake company frequently used by Microsoft to demonstrate how a service might be set up using a specific Microsoft product. "Example" because it wasn't a full implementation, but a usage demonstration of a specific component. Microsoft assumed people reading the examples would decide which components to use, so they were showing how to use each one, not telling you which ones you needed for any given task. Therefore:
"looked like it had crawled out of a Contoso example": Had the form of a solution without the content and was missing important elements that needed to be added.
"No back end": The code that was produced only shows the interface. You need the back end code to do any tasks. Given their assessment of the quality of the front end (part you see), they weren't very confident that it would have managed the rest.
Does that help?
I don't have a position on it either way, but those two statements come from the same source. Someone who doubts the first might also doubt the second, with the option that the author is exaggerating or inventing his history, that he has forgotten important parts of that history, or that, while having done exactly what he claimed in the past, he still doesn't have enough understanding or testing of his new tool to be so confident in its professionalism. Among other things, his claimed history with VRML could mean that the software is professional in its ability to do the tasks he's testing but doesn't necessarily prove that the code is professional, an important aspect if it is to be later maintained. Any of these things would have to be supposition without external knowledge of the author's skills and experience which I certainly do not have, but so would any assumptions that those statements are both true.
I think the Iraq War example is a lot closer to the mark than you claim and has similar restrictions and answers as the AI example, starting with a simple problem with your statement: "Technically, it would have been possible to do it in a week with WWII technology if it was politically acceptable to have high civilian casualties."
Fine, everything's on the table. You can carpet bomb, small nukes, kill anyone you want. What can you actually do within a week? If the goal was simple, find where Saddam Hussein is and kill him, maybe you could. Even then, all sorts of things could get in the way of that quick a timeline. That's a short timeline for finding a hiding place if he was fortunate enough to go to one. That's analogous to code that you only need to work once and can go wrong in many ways, and we do have plenty like that. If I can write something quick and dirty which will get the results I want rapidly, even if I cause several errors using the run first and check whether I followed the API requirements later, I can do that too.
If your goal is a little bigger, obtaining the surrender of Iraq's armed forces, now it's trickier. Oh, it might look easier because somebody's going to surrender when you're threatening to nuke Baghdad, but you don't just need them, you need everything. That's analogous to something quick but that you're going to run multiple times. Little bugs are no longer acceptable, but at least there shouldn't be so many you need to iron out because the task itself is small.
But neither of those was the complete goal, hence why the actual war was long. Debating the goal of the attackers is not relevant here, but no matter what you think it was, whether that's making Iraq a democratic country, eliminating terrorist groups resident there, preventing more genocide, weakening other countries' diplomatic or military positions without going to war with them as well, those are not simple goals and no level of weaponry was going to make that happen because the trouble was not easily locatable and bombable. Getting that after World War II took a lot of time, money, and some threatening countries that the allies were protecting the vanquished from, and repeating that is not easy either to achieve or to convince politicians and citizens to pay for. And that's what people who write software mostly need as well. They need software which continues to work long-term, that can be fixed or improved without rewriting big chunks, reasonable confidence that those little changes won't introduce massive new bugs, testing to confirm that, and correct documentation and understanding from those maintaining it. These are not simple requirements and current LLMs do not do them at all. Nor is it likely that just throwing more money at it will make that happen any more than more bombs in 2003 would have prevented ISIS from forming. There are some problems that can be solved by throwing more money at them, but diplomacy and inventing unproven technology tend not to be among them.
They weren't saying that the mechanism doesn't allow setting a price, but the generic anti-copyright "everything digital should be free at all times" crap. At least in the narrow case of their comments, they're correct; it is digital and it lacks any worth, monetary or otherwise.
There are plenty of free databases using SQL or SQL-like syntaxes, notably Postgresql (you still need to install it somewhere) and SQLite (works entirely portably). Licensing isn't really the problem.
The problem is that you can put a spreadsheet in front of a user and they'll figure out how to find an intersection between a row and column to enter data, but put them in front of an SQL CLI and they'll be immediately lost. Most systems that use a database have programmed UIs built specifically for it, and if you have those, they are generally quite helpful with two major drawbacks. It took someone with more programming knowledge to write them, so if you don't have one of those, you don't have them. And, if you need anything that's not already in the UI, now you've got an annoying process of trying to find someone to add it and the addition won't be a simple formula or view, a problem that gets worse if your change needs to change the database's structure by, for example, adding a column which some things will handle, most things will ignore, and some things will break on. That's why spreadsheets have and will continue to win for this kind of task. We have not succeeded at making anything better from the users' perspective.
I think that does account for a lot of users. In case people are interested in the blog we're talking about, it is here and it's from 25 years ago.
The problem with the complaint is that we're entirely correct that Excel has a lot of problems when used as a database but, from the perspective of most users, there isn't anything else for them to use. Following the same design advice from that post, we haven't considered what the people who don't have experience with databases need and therefore haven't built something that solves their problems. If we tried, we'd likely end up with something that looked a lot like a spreadsheet but just didn't do as many of the spreadsheet things. It's likely not very hard for us to write an SQL table schema to describe the data we're going to store and some input validation restrictions, either running at the SQL level or slightly above it. Both are foreign to a lot of people who need to create and store records with specific fields. Therefore, it's often quite difficult to figure out what to tell people to use instead of Excel. The stereotypical comment doesn't even try, just saying "a database" which doesn't specify what database engine or how they'd configure it and certainly doesn't cover the entry and display parts of the problem.
Some of them do have to use Excel, whereas others could use any spreadsheet but are so used to the Excel UI*1 that they don't want to change. In both cases, they could use it through a VM*2 if ditching Windows was desirable.
*1 Sometimes, Microsoft has changed the Excel UI and angered users. I knew many people who were very big users of Excel who got very unhappy with the introduction of the ribbon. But now that they've finally gotten used to that, they will react equally unhappily to any other big UI change including going to LibreOffice.
*2 I don't know if you can use Wine or related software with the full Office. I've never bothered to attempt it and my initial thinking is that something will go wrong. The web version of Excel is technically capable of the same things and looks sort of like the desktop version, but I have also never tried having someone who uses Excel a lot go that way and imagine that the decrease in speed would be as noticeable there as it has been whenever I've used that or Google Sheets.
Of course it needs changing. The problem in the text is the word "unauthorized". What does that mean? People who don't like that you've pointed out they've got a gaping hole often interpret that as "we did not like that you told us this, therefore you were unauthorized to do so". It's not defined, so what authority can authorize you to do what thing is entirely unclear. Do you need prior written permission to view a public site? How about to take apart hardware you legally purchased and own? Or take things I do at my job. I work in security and have plenty of authorization to poke lots of places looking for problems, including things we bought or licensed from others with access to our data. Do I also need authorization from those others to do that, with my employers' being insufficient?
In practice, this has no definition other than what a complainant and law enforcement are willing to accept. Therefore, if I find a problem, report it, and get threatened that if I say anything to anyone about this ever again, they'll have me arrested as an evil criminal hacker, I don't have any certainty that I won't find myself in police interviews and there's at least some chance I might find myself convicted. Probably not, which is why I still report things, but I know people who have gotten plenty of legal threats. The fact that I and most of those can point to professional work in security, will push back against threats, and are not asking for money act in our defense. We should not need any of those things to be able to report problems without fear, and there are people who don't have those and still have valid reports.
The analogy to doors is almost always flawed and makes this tricky, but I will try anyway. The difference is that these are doors in a very public space where the general expectation is that they will be unlocked and open unless the owners wish otherwise. Websites are intended to be accessed by all sorts of people from almost anywhere, and thus they should be treated differently than private property.
Consider a simple example: I'm navigating a website to download a driver I need. I click the link that says it's for the driver. I get a 404. So far, I'm accessing public resources available to anyone through paths created by the website owners. But now, since I didn't get the file the link was supposed to go to, I try removing the last part of the URL to go up a level. I'd argue this is still completely normal, no more invasive than going around the back of a shelf to see if they just misplaced it. If they don't want me to do that, blocking that is incredibly easy.
This brings me to a directory of files, and I choose the one that looks like it's the file I wanted. But when I open it, I discover that this is sensitive internal information they really don't think should be public. Have I broken the rules here, just because I didn't only follow their own links? Is it different if I followed someone else's link to the same page? In both cases, this is available to anyone who knows a predictable URL and would have been very easy to block.
This is not a theoretical example. This is an example I went through, reported to the owner of a website, and received an irritated response to. While they didn't go to the effort of threatening me with legal consequences, that does happen. I did not apply to the corporate headquarters for a written permission to navigate their website, nor in my opinion should I need to in order to avoid prosecution because they were unhappy that they put things they didn't want people to see there.
The information was sent to their personal email account. That's a lot more akin to having a key mailed specifically to you, and you would have a few reasons to try to figure out what it was doing there. For example, did you have an account you created years ago and forgot about, the most plausible reason that they would think there was an account using your address? Was someone specifically impersonating you, in which case you have a personal security reason to identify it and close it? In both cases, you would have every legal right to do exactly that because mail that is directed to you at an address you legally control is yours.
Good news, you can do that to any software you run on your computer. That proprietary blob that's Microsoft Windows: you can do that. You'll just be doing it with the machine code that gets executed which you can easily convert back to the more human-readable assembly. Have fun.
You are not owed every line of code someone wrote, no matter how much you want to have unrestricted and free access to it. If you don't want to run anything you can't read, then don't run proprietary software. It doesn't mean you can apply your favorite terms to any software or make ridiculous laws designed, not to solve any problem, but to force people to comply with your wishes. Nothing else works like that; I'm not required to give you all the manufacturing diagrams for a tool to remove myself from legal responsibility if you bash yourself in the head with it. It doesn't work that way with software either, it shouldn't, and it never will.
Your proposal would not work. The reason you cite, that it's really hard to make everyone forgo money when they don't have to, is only one reason it wouldn't. Another is that, if everyone sold their RAM at cheap prices today, that would only make RAM slightly cheaper for the average consumer. AI datacenters would not buy that because they're using different types of RAM than a lot of us. They're made at similar or the same facilities, but most of the RAM they are buying is either fast VRAM that's connected to the GPUs or slower ECC RAM connected to CPUs. It also wouldn't work because the secondhand RAM market is tiny compared to the new RAM market. It's hard to make a dent in prices when you start from that.
I doubt it. The initial shock may be a little faster, but markets already moved really fast in 2000, so I expect that the only difference is that the people who manage to sell before the shock is over will be more random and include more retail investors.
The big collapse after that will probably not be any shorter because that's the part that deals with individual humans trying not to follow suit. A company that still thinks it has a workable plan isn't going to fire everyone and declare bankruptcy a day after a market collapse. No, they'll say they're different and keep going until they can't raise any funds. That could still take weeks for small startup companies and months for ones that raised a lot of investment and have the foresight to not build the most expensive part of their plan and use that funding for extra runway. Except in this case, we have some of the companies with the most cash in the world participating. Microsoft and Google don't have to throw in the towel for a long time. They can keep insisting that Copilot and Gemini are different and that they will be the winners when the smaller models are gone while part of their bulwark of cash burns merrily. Their doing that makes it possible for related businesses to say that they're still able to operate. It will take some time for all of the people who will eventually give up to give up.
This is a good point and it can be extended. Bubbles popping are rarely as fast or as contained as comments predict. Fast ones still take weeks just to finish the first plunge, and the aftermath is much longer but less spectacular. Yet it's the aftermath that causes most of the problems. A few companies failing costs the employees of those companies and some suppliers or investors their jobs. A year of slow collapse costs far more jobs, but they happen slowly so people often point to that one spike. That goes for any of the consequences, whether RAM prices or tech hiring.
And this has to do with Rust how, exactly, since it was a Javascript dependency they didn't write? For someone who is complaining about evangelizing, you're doing a very thorough job of evangelizing how much you hate Rust even as you demonstrate that you lack any knowledge useful to proving any point you might have had about it.
That won't work. rm -i will just list files until you try to delete them, and only then will you find out whether you can. You can do manual stat calls to find out whether you can if you need to know that information. However, this sounds like it was from FTP, meaning your access is slightly different and normal terminal commands aren't what you're using.
But there is often a way to create user-specific passwords for something which you can then revoke individually rather than needing to revoke the common password every time a single user isn't supposed to have access anymore. In my experience, most shared passwords don't get revoked when someone leaves, so unless you're already doing that, you've failed, and if you are doing that, there's likely an easier and better option. If you have individual accounts, there are many situations where you never have to have a shared password for anything.
That's not what this is about. Vizio didn't put their own software under the GPL then try to not give out the code. That's because a) you'd have to be a complete idiot to do that and b) it's almost impossible to put the GPL on something you don't want to share, at least in the same way that it would be to sign a contract saying you agree to do things you refuse to do, and there would be several ways out of such a choice.
What happened here is that Vizio used other people's software and that software is under the GPL. They can't change that because they didn't write it. That makes any software sufficiently combined* with the software they used from others GPLed too. They can't change the license on that either without removing all the software that uses the GPL. So to do what you're suggesting, they would end up having to rewrite the parts that interact enough with the GPL.
* That said, "sufficiently combined" is somewhat narrow. The fact that they've got a Linux kernel in their TV doesn't mean that they have to release the application stack that runs on the TV. It just means they have to release the Linux kernel with any changes they made directly to it. I haven't read the details on this case, but from previous examples I've seen, none of the specific pieces of software mentioned in the article are likely to get interesting source out. Perhaps there's a different GPL component attached to something likely to be substantially different. I've gone through the effort of getting open source code from companies when it turns out to be almost the same as what I could have gotten directly from the source with changes that didn't make any useful improvement.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
