Comment Re:TACO Tuesday? (Score 0) 66
Yet another Trump back clown.
There, fixed it for you.
Comment Re:Four hours isn't enough (Score 1) 108
Based on what? Where did you pull the number 24 from, and have you consider how much storage you need to keep a 5kW tower running for that long (especially before lithium batteries became common).
What do you achieve in 24 hours that you can't achieve in 4 hours? Why not 48 hours? Have a think about this one carefully and consider what you do in an outage, consider what needs to be done to maintain contact, consider what the typical outage duration is and then justify why you think 24 hours is required.
Based on that it was 24 hours for landlines here (in Sweden). They just dropped that to much less for cellular because of the reasons you state. That was fine as long as there was both, but then the landlines went obsolete and the requirement was silently dropped. There are quite a few remote places here that gets severely affected when there are outages.
Comment Re:Four hours isn't enough (Score 2) 108
24 Hours is better of course, but for a "small" 5G tower that is about 125 kWh and a full size tower twice that. That is about 80 gallons of diesel or 1.5 tons of batteries. The way the 5G networks are set up it is a big ask, even if it is needed as emergency infrastructure.
I do understand the complexity, but then at least GSM infrastructure should have been kept, or even landlines to some extent. If 5G isn’t up to the task something else is needed to keep the society running in emergencies. Basically the question is: what is cheaper, backup or parallel infrastructure?
Comment Re:Four hours isn't enough (Score 1) 108
A minimum of about 8 hours is more realistic for cell towers and 72 hours for core network is what you need for reliability and recovery. 24 hours for the towers is better, but difficult to achieve for many sites.
I think 24 hours should have been a design criterion in the first place. If something is to replace landlines, then to me it feels obvious we couldn’t skimp on the reliability/uptime aspect.
Comment Re:Brain architecture (Score 1) 193
You obviously live in a parallel universe. I quickly lose trust in people who confidently claim they are sure, only to be proven wrong seconds later. I’m not alone.
Comment Re:Brain architecture (Score 1) 193
Well, it’s just not true. The fact that these LLMs fail this makes them way less usable. Think of a colleague doing the same. You’d quickly stop asking that particular colleague because you wouldn’t trust them. The first model solving the problem of rating its answer in a meaningful way would be a game changer.
Comment Re:Brain architecture (Score 1) 193
You can train an LLM to say it doesn't know, or even build pretty good objective confidence metrics. We don't, because people don't like it. We don't like it in humans either.
Who are ”we”? Not being able to say when it doesn’t know is LLM’s biggest flaw! This very ability is what builds trust.
Comment Re:Why would it? (Score 1) 231
Besides windows being a bit of a sluggish mess, I’m not particularly fond of its default window manager. Developer are replacing the os part by running linux under wsl, maybe there should be a way to replace the window manger as well? Oh wait, what’s left? :)
Comment Re:next up: no compilers allowed! (Score 1) 70
I see what you did there but LLMs aren't compilers. There is no source code except the prompts, and those do not really work for someone else to later add stuff or fix bugs.
If there was working source (prompts) that could be revision controlled and that could be patched and regenerated, then I guess it would be workable to not tinker with the generated code.
You wouldn't compile your C once, and then force any fixes to be direct binary patches to the executable, would you?
If there was working source (prompts) that could be revision controlled and that could be patched and regenerated, then I guess it would be workable to not tinker with the generated code.
You wouldn't compile your C once, and then force any fixes to be direct binary patches to the executable, would you?
Comment Re: Isn't that the point? (Score 1) 70
Why shouldn't it be repeatable?
I hate how people hear the word "stochastic" and without understanding think things would be random. Same Input (Seed is a part of that) gives same output. 100% repeatable. If you don't like having a seed controlling variance, set the temperature to 0.
Ok, fair point. However from what I have seen the current set of tool aren't really supporting this kind of repeatable workflow (yet?). You'd need to be able to store the seed/context window, and a repeatable reference to the actual model used.
Comment Re: Isn't that the point? (Score 2) 70
If you can't understand the code as allo writes above, then the prompts leading to the code is all you have. If that is not repeatable, how do you even know what to modify?
There might be some process here that can be used as a sustainable workflow but it's not at all obvious.
There might be some process here that can be used as a sustainable workflow but it's not at all obvious.
Comment Re:What's next? No auto-complete as well? (Score 1) 70
i would add that "inconsistent style" might be not very reasonable either (ai or not) but that's just my subjective view on an often controversial and context-dependent topic. i'm not at all against style guidelines per-se but there is a point of diminishing returns, and in general code should be clear and self-explanatory regardless of style. if code is hard to read because it isn't (clear and self-explanatory) that's a problem with the code, if it is hard to read because it deviates from the style guide that's a problem with the style guide or coding culture/habits.
"inconsistent style" can create problems when doing maintenance of the code base over time, different files use different libraries for the same thing and so on. Makes traversing the code much harder for someone trying to add something.
Way back at my then workplace there was a guy who refused to write anything in ANSI C, he only did K&R. I guess it was consistent within the portion he was working on at that particular time, but it kept others out of there.
Comment Re: Isn't that the point? (Score 1) 70
It's not really the same as the process of using an LLM to create the code isn't repeatable. You might not get sufficiently working code feeding in the same instructions.
The equivalent of this using a traditional computer language would roughly be to compile the code into binary, and then throw away the source code.
The equivalent of this using a traditional computer language would roughly be to compile the code into binary, and then throw away the source code.
Comment Re: Isn't that the point? (Score 1) 70
This is an interesting perspective. I have a similar time of experience 25+ years in embedded development. We didn't always have formal code reviews, but I've rarely not worked in a team. Usually 3-4 people in the same discipline as me, and then cooperating with other disciplines.
But as our perspectives are so different, I can't help to wonder what the actual ratio between single devs and team devs really is? Never seen a study on this.
But as our perspectives are so different, I can't help to wonder what the actual ratio between single devs and team devs really is? Never seen a study on this.
Comment Re: Isn't that the point? (Score 1) 70
Ok, but are these people then performing their job adequately?
If you are working in a team that uses code reviews, what do you do when you get a question about some part you don’t understand? It’s going to be pretty hard to get the PR approved in a well functioning review process.
