Copying what I posted under the original[0] that no one noticed because it's quite relevant to your mention of UTC for past events:
The naming of "timestamp with time zone" is one of my favorite pet peeves. It's one of those things that you can say "well technically it's true" about.
The article suggests that for past events, UTC and this timestamptz would be acceptable as a general rule, but even there it depends on what you will be doing with the data. If you intend to interpret it as a series of local occurrences and try to visualize/summarize that data later, you may be in for a surprise as your user has moved to another timezone and now all the past events are translated to the wrong local hours [1]. For example, your system might end up showing that the user's best time for jogging based on historical data is at 2 in the night.
Correct: "never talk to the police" is a very online belief. I watch people talk to police all the time. People go out of their way to do it.
I don't even know what to do with the "never date police officers" thing. Most police officers are married. It's a shift-work job, so they have high divorce rates, but they just remarry.
RAM is expensive now. Reasonably priced seems to be counter to that fact.
The whole article feels like a promo-tour.
> The catch is that nobody handed us the tools to keep the place running.
Software such as homebrew exists. Why is the article ignoring this? Not only does it feel like promo, it now feels like propaganda. Homebrew is also just one example; LFS/BLFS also exists for embedded linux. Perhaps the quality is less than for desktop computer systems but it exists.
> Edge devices have started behaving like cloud systems. They run increasingly complex stacks, are frequently updated, and are managed remotely over their entire life.
Companies want to become dependent on others? Because that is what cloud is all about. Top-down control. A mafia for later blackmail rack-up-the-price strategies.
> That puts the cross-compile burden squarely on embedded developers, and maintaining recipes for thousands of packages has been a steady drain on the Yocto community
Seems untrue. If you have a compiler that works, you can compile. Thousands of packages? I am tracking 3888 right now. That covers really most software by far, including python pypi addons. If a single person can do that, a team has an even easier time. The whole article seems to narrate a story that is just made up.
> Building everything from source in Yocto means long builds, heavy memory use, and powerful workstations.
No it does not. I do so every day. You need a reasonably fast computer and RAM, which is now driven up by the existing hardware mafia that must be put in jail, but it is easily possible for solo persons too. Now imagine a team.
The whole article is really really crap. Absolute garbage. The claims it makes are for the most part simply not correct. It narrates a story as if all linux developers are incompetent. I highly doubt that. It also never mentions any existing software here that would change the rhetoric such as homebrew, LFS/BLFS and so forth. It feels as if that article is just engineered to tell a "we thus need xyz". That's not good writing. I mean just look at this:
"We can leverage these change agents and rethink the world of connected products."
What does that even mean? Did AI write this? Because humans are usually smarter when it comes to opinion pieces. "connected products" - everything is now connected?
Most of those options are overlapping and redundant though. Only the total range really matters, by simplifying the front the whole system becomes easier to use and mechanically less complicated.
So my first thesis that I want to prove is - are all enterprises going to start self hosting open source models ? If yes, then one will need to deploy a solution around the models to act as a firewall. A firewall fine tuned for the context that’s coming in and coming out of a model. Way different from how microservices work today.
You're engaging in a pretty common fallacy by taking the contemporary standard, in a world full of wild inflation and funny money, retroactively applying it backwards, seeing [correctly] that it wouldn't work, and thus concluding that funny money is needed. But you need to consider the impacts of the funny money itself.
One fundamental difference is that inflationary systems incentivize the hoarding of 'things', like housing, as a means of escaping inflation. This is because the price of 'things' will always increase with inflation. But in stable or deflationary systems there's no inflation to hide from and the price of 'things' is stable or can even decrease over time, so there's no longer a hoarding incentivization for 'things', though there is one for money.
So you can see a visible impact of this in housing prices. In the 50s a typical house used to cost about 2 median salaries. [1] Go further back in time and you're down to 1 median salary. In modern times, we're at historic highs of a median home costing 5x a median salary, and in desirable locations like western California it even gets up to 12x local median salary for a median home. [2] I'm spamming median here to emphasize we're not talking about Beverley Hills or whatever.
So yes, in modern times you need endless funny money to do achieve even basic societal things, like owning a roof over your head. But that's because of the funny money. And this is before we get into realities like the fact that when the government 'prints' a trillion dollars, most all of that is going to end up in the pockets of the wealthiest of society giving them even more money to speculate with, driving prices up even more. And much more, there are endless self feedback mechanisms that have left us in a vicious cycle that's probably inescapable at this point.
Real wages are up 14% over the past 47 years [3], and we now have a trillionaire. That's inflation for you. What do you think they'll call this era in the future?
Nor have I, I’ve never even willing clicked on an ad, but I see countless others do it when I watch over their shoulder.
I’ve also seen seemingly normal people argue in favor of user tracking and data harvesting so they could get ads that were more relevant to them. They claimed they genuinely found them useful.
To me it's not even the comparison with builds that's damning; it's the comparison with handhelds and other mini PCs. Most people excited by this probably have a Steam Deck or another handheld, so they have to be into playing a very specific slice of games that can run slightly better than the handheld.
For example, Forza 6 on high 1080p is 60 for SM vs 40 for high end handhelds and 30 for SD. Even at the original price, is it really worth $750? Not to mention that many handhelds and mini PCs also have USB4 ports that one could attach a retired GPU to get 60fps+ @ very high 2k, but the Steam Machine has no such port and only one NVMe slot.
So this is for people who are allergic to the existing solutions (plugging in your handheld, using Moonlight) or just like the brand, but I know it's going to still sell out. I just don't want to hear about extensibility, eco-friendliness, or cost effectiveness from a certain segment of gamers after this.
... the entire point of the decision was whether a person has an expectation of privacy in a rental car outside of the rental period.
The court didn't come down in favor of warrantless use of ALPR data. It said that the defendant did not have standing to challenge the use of ALPR data, warrant or not, because said person had no expectation of privacy in a vehicle they had no legal claim to during the period the data covered.
FFS, the court, in the opinion, which you linked to prove you're smart, quoted, verbatim:
"We do not address the potential Fourth Amendment privacy interests that may be implicated by the warrantless use of this ALPR technology because we conclude that Yang does not have a reasonable expectation of privacy in the historical location data of the Yukon under the facts of this case."
The Steam Deck is an ok PC gaming machine, but most PC games aren't optimized for console experience. There's even quite a few Windows games that don't work or have bugs on the Deck. Meanwhile all Switch games are made for that platform and there are a ton of exclusives you can't get on PC. Glad each one has a niche, but Switch is an order of magnitude (or two) more successful than the Steam Deck.
If you're going to gamble, it's probably for the best that your counterparty doesn't also control the platform. I'm not saying that justifies being able to gamble frictionlessly, but it is marginally less exploitative. Eg, back in the day bucket shops (which sold binary options, like prediction markets do) would increase the spread in proportion to their assessment of your skill such that you would lose even if you were more skilled. In a proper market the platform makes the same amount of money whoever wins.
So, not all that different, but marginally less exploitative. I've never looked at Polymarket but Kalshi and PredictIt slid steadily from things of at least plausible real economic value (a market where it was conceivable [if unlikely] someone would be hedging their insurance contract or something) into total nonsense with no non-gambling function like whether someone would tweet a certain word.
I think prediction markets could serve a similar to a futures markets and have a functional purpose in the economy. It could be useful to generate real time estimates of the probability of some events that no one can control and have real economic consequences, like a hurricane. But evidently that's not where the money is.
Tl;dr it’s still above the IPO price so the favoured investors still at a profit and Musk is still a trillionaire.
As with Tesla, Musk will keep coming up with ‘profits suck but we are doing x new shiny project so don’t worry’ announcements to keep retail investors believing…
I'm not seeing any mention of tools in the paper, much less a bias towards "curiosity" to use those tools when it encounters gaps in its knowledge. So perhaps this is a good proof-of-concept that single-pass code generation is viable with this small a model - but we're still a long way from a viable solution.
Depends what you mean by viable. Solar is easily economically viable, but integration at grid scale is tricky when your peak summer generation is 10x your winter generation.
Honest question: why would one switch from a much more capable "carry everywhere" smartphone camera to this? Especially since phone is truly carry always & everywhere and that computational processing squeezes out insane amount of photo quality from already excellent phone cameras.
>Every package install is checked against the threat feed and it raises an exception if we find something malicious being installed.
So your solution is to reinvent signature based antiviruses, like Norton Antivirus and McAffee?
The problem with these 2000s approaches were that attackers could:
1- Fuzz their payloads so that they are never the same and they don't trigger detection.
2- Offload payload mechanisms so that your monitoring system needs to play cat and mouse. For example, what if the malicious code does wget https://IP/file, will you detect wget commands? Will you scan for whatever looks like a URL? Ok, what if they do "another_package_manager_like_flatpack malicious_package", will your scanner implement all package managers? What if they construct the url? "protocol + "://" + domain + file" surely your global hook thing will notice that is a url and how it is downloaded and inspect those contents as well?
3- The attacker can control the timing and infect every user at the same time, especially if they control the update mechanism of users whose security policy is to keep things patched. Even if the malicious update is not simultaneous, the malicious update can start distribution, and the attack only triggered months later (simultaneously) when enough users have downloaded it (beating latency policies).
The only solution is to do actual work and either write the thing you are trying to offload to the 'open source community, or to actually write it yourself. But of course more work is going to be put into the possibility of a magical easy solution, than on an deteriministic hard solution.
Agreed. More importantly, this long documented history of massive recurring multi-billion dollar fraud and theft – mostly from domestic and international retirement funds – indicates that America is essentially, for all intents and purposes, a plutocratic dictatorship with the illusion of democracy. Ticking a box every few years, when all your options are pre-positioned to continue a criminal status-quo, is neither "democracy" or "by/for the people". This systemic corruption did not materialise out of thin air recently. It has arguably been present all of history (in every economy). It's just accelerated to psychopathic levels of obscene gratuity over the last 2 decades.
This is why I've voted with my wallet the only way I can, by moving all of my investments (including retirement) out of the American market. The rot is far too deep. The few bad apples have entirely spoiled the bunch. I'm not under any illusion other markets will be safe from the fallout, or that I'll make better returns long term, but I do not care. I'm voting the only way I can given the current system. If I'd moved my investments earlier, when I came to this conclusion, I would have actually made significantly larger gains over the last couple of years.
Thats not a complete reasoning. Even frontiers need to revisit and fix things. Add 10 loops to that and it is 20 hours. Still great compared to a 2023 human, but why am I not just paying pocket money for Claude Pro instead?
> Gas is the cheapest, fastest zero-to-production choice for onsite power generation, and has been for a long time.
Last I heard the wait time for turbines was ~5 years at the moment. I'm sure MSFT has some inside baseball with Chevron but it doesn't work as a general rule of thumb.
This model doesn't support tool calling, was not part of its training. It's focused on Python (and I think C++) competitive programming and mathematics tasks, i.e. tasks with verifiable rewards. So if you have a task that fits that description, the size-to-capability ratio is good.
The naming of "timestamp with time zone" is one of my favorite pet peeves. It's one of those things that you can say "well technically it's true" about.
The article suggests that for past events, UTC and this timestamptz would be acceptable as a general rule, but even there it depends on what you will be doing with the data. If you intend to interpret it as a series of local occurrences and try to visualize/summarize that data later, you may be in for a surprise as your user has moved to another timezone and now all the past events are translated to the wrong local hours [1]. For example, your system might end up showing that the user's best time for jogging based on historical data is at 2 in the night.
[0] https://news.ycombinator.com/item?id=48558005
[1] https://blog.nytsoi.net/2022/03/13/utc/