Comment Re:Well "just" vibe code you a new API, then eh? (Score 1) 34
create an open source API
That's what OpenCL is.
There's a small performance hit because OpenCL runs on any GPU, whereas CUDA is tuned only for Nvidia GPUs.
create an open source API
That's what OpenCL is.
There's a small performance hit because OpenCL runs on any GPU, whereas CUDA is tuned only for Nvidia GPUs.
I'm not sure why this is modded Funny. It should be modded Insightful.
Modern AI is pretty good at rewriting CUDA as OpenCL.
It's not just one click (yet), but AI can do 90% of the work with some human guidance.
AI can also create a test suite to verify that the translation is correct.
They actually said other tools are regularly used and have been known to find hundreds of issues. So, no, their awesome code is not the reason. Mythos just sucks at finding vulnerabilities that other tools haven't already found.
FTFY.
too many folks are still stuck on IPv4
Printer is IPv6 only?
What I'm saying is that if everyone had IPv6 in their homes and offices, remote access wouldn't require all the silly cloud server games. You could just hit the device directly by its IPv6 address, and assuming your router suppoerts UPNP pinholes, you're done. You'd need dynamic DNS and that's it.
I can understand the remote printing (not on the same network) part. But only up to the point where something jams and I'm not there to yank the plug and untangle it before it gets hopelessly borked.
An emergency stop button in the app should be able to do the same thing. If that's not possible, it's a rather bad design flaw.
Also, if something jams in a way that could cause meaningful damage (beyond having to brush blobs of filament off of the hot end) and the printer doesn't detect it, that's also a rather bad design flaw.
I've been through more than a few technology cycles, so while I don't necessary disagree with you, the scale of the disconnect between the worker bees and management is more significant than I ever remember.
It's becoming exceedingly difficult to dissuade management from AI courses of action, even when they make no sense or will end up delivering a substandard product for significantly higher cost.
For instance, I just had a client implement an AI auto-attendant for a medical office. Were they having difficulties answer the phone in a timely manner? No. Do they anticipate a staffing shortage that would cause such an issue? No. Will the auto-attendant be able to accomplish what a regular worker can? No. In fact, it can pretty much only answer the phone and find someone for the caller to talk to.
But by god, management had to have it. So, for an extra 2000 a month they get a middle man that delays delivering service to patients. Management loves it. Folks answering the calls hate it because the patients hate it.
Different office asked about AI curated music. Another client asked about replacing our network monitoring software with AI so their IT staff can stop working after hours. They both will end up getting their wish, and at least in the case of the network monitoring solution it's going to cause so many issues I'm having them sign a waiver before I implement; I won't be held responsible when the AI agent is rebooting servers randomly because it thinks they're offline.
More than any other IT fad over the past 2 decades, I've noticed AI has really divided "decision makers" and "makers/workers". Those of us in the trenches making things work are highly skeptical of AI and treat it much as we have any other "flash in the pan" technology; weary, willing to test/play with it, but disbelieving of the hype.
The decision makers though...whoooboy, they've bought into the tech hook, line and sinker. They want AI everything, even in places it makes no sense. They can't define what they want AI to do, or how it's supposed to do it, but by god they will sign away millions of dollars in pursuit of their golden cow.
The only time I really saw anything like this was with "Teh Cloudz!", but even then it was tempered by practicality. AI? It's magic beans, all the way down.
I have an F-150 Lightning. It's 2 $200 parts to convert from NACS->CCS1 (one for DC, one for AC). The connector type doesn't matter. CHAdeMO requires an adapter that costs thousands. It's not comparable.
CHAdeMO to Tesla adapter: $565. If adapters in the reverse direction from NACS to CHAdeMO cost thousands, it's because the market is too small to achieve economies of scale. Yeah, you need some active electronics to negotiate the protocol, whereas NACS uses the CCS protocol, so you can do it with a passive adapter, but the actual DC is still DC.
About the only thing any cloud service for printing provides is a way to monitor the printer and send jobs to it when you're not on the same network. And the only reason this is still an issue at all is that too many folks are still stuck on IPv4.
I like their products. I just want printing without fuss and without having to learn every detail about leveling, etc. Their product works for me and I do not care about its openness, it is about as important for what I need it as my headphones being open sourced (not at all). So this product is for my use case, not for people who want to control every aspect of their printer and every software feature.
The problem is that their model works until it doesn't.
Having a good out-of-the-box "it just works" experience doesn't preclude letting people tinker. If anything, letting people tinker results in a better out-of-the-box experience in the long term, because the manufacturer can see what people are doing with their technology and can clean it up and make it more broadly available if it is useful. The key is ensuring that the default experience doesn't require tinkering for the majority of customers. And seeing people tinker shows you where the sharp edges are that need to be polished.
But more than that, locking down this sort of hardware means that when you inevitably run into some limitation, if the manufacturer doesn't provide a way around it, you're stuck. And the problem is that a lot of users of advanced tools like this are in a situation where 90% of their use is common to all other users, and 10% isn't. And different users have different 10% use cases. So you could be in a situation where 80% of your users need one thing that your product doesn't support, but it's a hundred different "one thing"s. This makes support very difficult if you don't allow tinkering.
But the worst part is that you can't know for sure whether you're going to be in that 80% until you run into the use case that they don't support out of the box. It could be a week, a month, a year, or several years. And then you're stuck with this hardware that won't do what you need, with no way to fix it, thus forcing you to replace it with a product from some other manufacturer.
So even if you don't think you will ever want to tinker with your 3D printer, assuming all else is roughly equal, you're better off choosing the printer that gives you the most control of the hardware, because that is the least likely to box you into a corner and make you regret your purchase someday.
Same discussion as 30 years ago with open source clones of messaging apps such as ICQ. The open source client pretends, on those days through reverse engineering, to be the official client. Ultimately, it was okay then, because it was beneficial for the operators to have a larger network of users who can talk to each other. Does this dynamic apply here?
I'd have gone with "Every web browser is Mozilla", personally, but yes.
If you're using a user agent for any sort of security purpose, you're not just doing security wrong; you're doing security so wrong that somebody is going to write an entire book as a postmortem about your company.
Moreover, if your service can't handle the traffic of a mere thousands of clients (four-digit QPS) hitting it at once, you have much bigger problems than security. I forgot how to count that low a long time ago.
Finally, the elephant in this room is that those "unauthorized" clients are YOUR USERS. They are people who bought YOUR HARDWARE and want to use it with your service. Basically, you're flipping off your paying customers. That's the fastest, easiest way to ensure that you don't have any of those anymore.
Threats of lawsuits (especially to open source products, which do not have deep pockets) are the new corporate approach to what would appear to be appropriate reverse engineering. The only way forward, if you disagree, is to refuse to purchase any Bambu products.
Already done. When I was choosing what 3D printer to buy to replace my aging Snapmaker A350 last year, I read about Bambu's questionable commitment to openness, and decided to buy a Creality printer (K2 Plus with CFS) instead. Over the year that followed, I bought a Creality Hi with CFS as a second printer, plus two additional CFS units, a filament dryer, a spare Creality tool kit (since the Hi doesn't come with one), and more than half a grand worth of filament.
I've personally spent well close to $3,700 on Creality products in the last year (not counting third-party filament and the DXC2 extruder upgrade) precisely because Bambu comes across as being a bunch of litigious a**holes who are trying to lock down their products and prevent users from being able to modify the hardware that they bought.
As far as I'm concerned, they've dug their grave in the 3D printer market. Stick a fork in it. They're done.
We are not going to build the capacity because that would require tax dollars
Building generators does not require tax dollars.
they're not going to pay for you to have electricity
Of course not. We buy electricity from the utilities. They don't pay us to take it.
That's actually a smart strategy.
But I wonder how many employees will quit in today's job market.
They've had 22 years to figure this out, but now it's a crisis requiring a rush mission because nobody thought it was important enough to do something a year ago, or five, or ten.
The term Celsius comes from the Swedish scientist Anders Celsius who set the freezing point at 100 and the boiling point at 0. One year later the French scientist Cristin reversed that and called the scale centigrade, because the scale was divided in 100 parts, with centi for standing for one hundredth. Celsius and centigrade are the same, and for some time both terms were used, but in the mid-20th century Celsius was adopted as the standard name.
Exactly. Only insecure people would be offended by a term that has been and is understood world around.
Besides, the cool kids use Kelvin anyhow.
Some people manage by the book, even though they don't know who wrote the book or even what book.