commandar

>So... Security through obscurity?

This is not a valid criticism on its own.

Security through obscurity is bad when obscurity is the only thing stopping an attacker. It's a meme because obscurity is not a substitute for stronger security mechanisms. That does not mean it cannot be an appropriate compliment to them, however.

If I wanted to hide a gold bar, sticking it in an open hole behind a painting on the wall wouldn't be particularly great security. As soon as a robber found the hole, the entirety of my security is compromised.

If I put it in a safe on the wall, it's much more secure. The robber has to drill through the lock to get the gold bar.

If I put it in a safe behind a painting on the wall, the robber has to discover that there's a safe there before they're able to attempt drilling through it. Bypassing the painting is trivial compared to bypassing the safe, but the painting reduces the chance of the actual safe being attacked (up until it doesn't!)

Security should be layered. Obscurity will generally be the weakest of those layers, but that doesn't mean that it has no value. As long as you're not using obscurity as a replacement for stronger mechanisms, there's nothing wrong with leveraging it as part of a larger overall security posture.

>that NIST has killed in competent circles

Just because this is my favorite soapbox - anyone that has to deal with passwords should go read NIST SP800-63B:

https://pages.nist.gov/800-63-3/sp800-63b.html

I was kind of shocked by just how gosh-darned reasonable it is when it came out a couple of years ago. It's my absolute favorite thing to cite during audits.

"Are you requiring password resets every 90 days?"

"No. We follow the federal government's NIST SP800-63B guidelines which explicitly states that passwords should not be arbitrarily reset."

I've been pleasantly surprised that I haven't really had an auditor push back so far. I'm sure I eventually will, but it's been incredibly effective ammunition so far.

The option is not a binary between "let it fail" and "no strings attached bailout."

If things get bad enough for Intel, the precedent that makes the most sense is to follow the model that was used with GM: the company enters bankruptcy, existing investors and creditors are wiped out, and a new corporate entity backed by the fed.gov steps in and assumes the assets and operations of the company. Once things have sufficiently stabilized, the government can then divest its ownership in the company.

Intel is economically and strategically important enough that just letting it collapse without a plan to pick up the pieces is a serious footgun. We have a framework for handling this kind of situation that has been shown to work without rewarding those who caused the problem. It'd be silly not to use it.

"Clearly, it is the user who is wrong."

>Anthropic is doing fine for technical or business customers looking to offer LLM services in a wrapper

If there's an actual business to be found in all this, that's where it's going to be.

The consumer side of this bleeds cash currently and I'm deeply skeptical of enough of the public being convinced to pay subscription fees high enough to cover running costs.

I just looked and I can't find any option to localize results more specifically than "United States." I'm not finding anything in a KB search either. If the option is there, it has really poor discoverability.

I love the service, but poor local results is definitely one of its weak points and basically the only reason I ever fall back to Google anymore.

The push for the 8 hour work day over a century ago was often accompanied with slogans to the effect of "8 hours work, 8 hours rest, 8 hours for what we will."

5 hours round trip commuting a day is giving up over half of your prerogative time to simply shuffling from one place to another.

The Bay Area is lucrative monetarily and all, but there's just no world where that's worth it for me.

Yeah, that's specifically what Matter+Thread are intended to address. The intention is that most devices that aren't battery powered and have an internet connection can act as a Thread border router and build out a mesh from there. The controller can be practically anything from that point.

>I really wish that what we got instead of "Hey, your device can connect to smart-things.com and do stuff, ain't that need!" we had "Hey, this device speaks Protocol 1.2.3 over bluetooth which you can import to smart-things.com or other services".

I made a conscious decision to build out absolutely everything HA-related that I could using Zigbee and Z-Wave devices. I intentionally avoided anything based on wifi and proprietary apps. It's basically what you're describing. I switched from SmartThings to Home Assistant about a year ago, and everything flipped over without any real drama.

As others have said, Matter is another step in this direction with the end goal of making setup a little bit easier; it's still incredibly immature at the moment, though. But Z-Wave and Zigbee are both here now and work fine.

Mixed bag, IME. Some vendors will work with you, some stick to their guns.

Either way, it's a surefire way for a potential vendor to automatically get lower priority from me as a potential buyer. Needing to haggle over what is, for us, a baseline security feature starts things off on the wrong foot.

FWIW, I've mentioned elsewhere in the thread, but I'm in healthcare. SSO (and MFA) have only really become hot topics in the past 5 years or so.

In the past? People with enough weight would absolutely blow right past implementing SSO if it was slowing them down or adding to their cost.

These days it's a hard requirement for us: if it's not SSO it doesn't go into the environment. That's becoming the norm across the industry.

This is one of those very, very rare cases where healthcare is probably ahead of the curve relative to a lot of other industries. Consequence of being highly targeted by attacks and insurers starting to get very particular about how the ship is run.

>This is from a random website with no credentials that makes no arguments to back up its claim. It's meaningless.

Appeal to authority. Meaningless.

All I was pointing out with those links is that literally Googling the term "SSO tax" and clicking the first link at least hints at some of the reasoning behind people making an issue of this. The fact that TFA doesn't address any of the actual concerns people have in any meaningful way makes it of incredibly limited usefulness in the overall discussion.

> The situations of "hardware shipped that can't be unlocked until user pays" and "paying additional to support a feature that takes a lot of effort to develop, and actively takes more effort from the vendor to support" aren't remotely comparable.

Then charge for the support. The issue is that the only way to purchase a core security feature is bundled in with other features that the user doesn't necessarily want or need, very often at several multiples of the price for the features they do want.

>That doesn't sound very believable to me - small businesses are both disproportionately smaller targets, and also have much less complex IT systems with fewer logins to manage.

This is working from the faulty assumption that potential customers only exist in a binary between the nebulous "enterprise" and "small business with barely any IT competency."

I live in the enterprise healthcare world. It's routine for us to consider software purchases at the departmental level to fill a specific need for a particular team. We have hard requirements for SSO. Some of it's driven by internal policy, some of it's driven by auditors increasingly demanding MFA everywhere.

I have personally killed deals over this exact issue on a more routine basis than I'd like. Department head thinks cost is going to be Y. Cost is actually 5-10Y because the only way to purchase SSO support is via an "enterprise" bundle with additional features they don't need and an inflated minimum seat-count buy. We'd happily pay some middle ground for SSO support, but the option to buy it doesn't exist.

The issue is not charging for things that have support costs; it's forcing a customer into drastically higher pricing tiers under the assumption that running SSO is a signal that a potential customer has a super sophisticated environment and bottomless pockets. That was the world of 15 years ago, sure, but it's not today.

The reality is we live in a world where there are increasingly strict security requirements in many industries and any business paying, e.g., $6/user/month for Microsoft 365 has SSO available as an option.

I'm in the healthcare world.

SSO is a hard requirement for us.

There have been many, many times where we've considered an application where we could justify the spend at, e.g., the departmental level for the limited user base that needed it, but where SSO being bundled into higher price tiers combined with minimum user counts took a potential solution from "very easy discretionary spend" to "not happening, full stop."

I'm often the one having to make these decisions. It's absolutely exhausting having to explain to non-technical department heads that "yes, this would solve your problem at a price that fits budget, but the vendor bundles a vital security feature into a tier that inflates the price to a point that it makes this unfeasible."

>This is a solid objection that I hadn't considered before!

To be quite frank: this strongly suggests that while you put a lot of effort into writing a long article in defense of the SSO tax, you didn't perform more than the most cursory research about why it's a topic of discussion.

This argument is literally above the fold on the two top search results for the term.

>In short: SSO is a core security requirement for any company with more than five employees.

https://sso.tax/

And the other explicitly makes the car-safety analogy:

>Imagine buying a car and the manufacturer asks for an extra payment to unlock 100% of the braking power. Not offering security features if they already exist in your product means a vendor doesn’t care about your security. Our aim is to spotlight vendors who overcharge for security features, in hopes of instigating a change in the industry.

https://ssotax.org/

And to be franker: the word "security" appears exactly once in your entire piece. That's a near-complete avoidance of the actual issue that people are highlighting.

I perfectly understand the rationale behind the pricing model. The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer. That is and should be unacceptable.

>If you pay before the billing cycle comes due, the banks will first insist you don't need a high credit limit and they will also insist you're a financial risk.

Not my experience at all. I pay multiple times per credit cycle and have never had an issue getting CLIs. My total available LoC is a few of multiples of my annual income and the only reason I stopped asking for CLIs is because I got bored with it and had enough available credit that I basically never carry more than a 1-3% total balance even if I'm floating large purchases.

I'd go farther and suggest that this advice is potentially harmful with the recent changes to FICO scoring where balances have a rolling average impact -- having a balance hit your credit report because payment posted after your bank's reporting date will now follow you for considerably longer than in the past.

Discover and AmEx are pretty generous with CLI requests IME. I went through a period where they both seemed intent on being my highest LoC card and would often unilaterally extend a CLI after a CLI from the other hit my credit report. BoA is also fairly generous. Citi and Chase seem to extend more grounded credit lines. Wells Fargo is hilariously stingy.

The big thing with any of them is asking, though. None of them unilaterally offer CLIs very often IME.

All IME, YMMMV.

It's really hard to overstate how much of a sea change git was.

It's very rare that a new piece of software just completely supplants existing solutions as widely and quickly as git did in the version control space.

In many major cities, racism being a major factor in the development of the suburbs is plain undeniable historic fact.

Atlanta, for example, may have been known as "the city too busy to hate" but continues to suffer from many issues that are a direct result of white flight and deliberate efforts to keep minorities out of the suburbs. It's why the METRA train lines and public transportation in general has such limited coverage. It's why the metro area is a mess of disjointed services. It's why "Atlanta" has a population of over 6 million but the City of Atlanta has less than half a million residents.

None of this happened by accident. In the most extreme case, a 30 mile long, 10 foot wide city existed for decades solely to contain the City of Atlanta.[1] This happened in less blatant ways all over the metro area and bitter fighting to keep Atlanta out (with "Atlanta" being unsubtle code for "minorities") was a recurring theme throughout the 20th century.

The people living there today may not necessarily be racist, but the existence of the suburbs themselves is pretty directly attributable to racism. Some of those burbs are majority minority today; that doesn't mean that their formation wasn't racist or that that history doesn't have real knock-on effects.

[1] - https://www.wabe.org/how-atlanta-was-kept-out-cobb-county-10...

If you need everyone working an incident physically around the same table in order to respond effectively, your organization is not equipped to respond effectively to incidents in general.

I'm speaking as someone who worked full time doing nothing but incident management at a F500 for a couple of years before the pandemic. The incident team for literally every single response I ran in that time was effectively remote; most weren't in the same building as me, probably weren't in the same time zone as me, and it wasn't unusual for them to be on a different hemisphere entirely.

Physical proximity to one another has absolutely nothing to do with the ability to work an incident. Effective communication is vital, but this isn't uncharted territory. Large organizations have been doing this effectively for a very long time before the entire in office/remote debate ever became a popular controversy.

The client shipped with Windows is literally OpenSSH.

It does. I use Windows Terminal and the native OpenSSH client literally daily.

I have a wall charger that triggers the liquid detection on my Samsung phone if the charger has gotten tugged partially out of the outlet. I use the same charger literally every night and it works fine.

I'm incredibly leery of this functionality being used to deny warranty claims as a result.

>So your theory is anecdotal.

It's based on basic engineering principles. Prusa can't magic away physics and these are lessons the rest of the community learned years ago. E3D had to course correct on some of the same mistakes with their toolchanger. There are good reasons why nearly every other CoreXY design you're going to encounter uses a closed frame (and the best will use structural panels).

>I think what Bambu has done is incredible but these are different machines for different reasons.

Sure, it's got its niche. But the drawbacks will narrow that niche. Prusa's ever narrowing niche is kind of the focus of the OP.

> The XL has a massive print area

Which makes running slow compared to other designs more painful since print times are cubic with volume.

>just spouting opinions without data or truly understanding the differences between the machines.

If you showed me a square wheel, I can tell you it's not going to roll particularly smoothly without needing to perform extensive testing on that specific implementation of square wheel. I can do that because it's something that's been tried elsewhere and we already know the results.

This style of open frame has been tried before. We know Prusa didn't choose to use it because there's any sort of engineering advantage because Jo has explicitly told us why they're using it.

Pretty much anything that looks like a box. Most anything from Voron, Annex, Rat Rig, VzBot, etc.

Or if you're looking at an XL, add a frame member across the front and a vertical frame member on each side.

This is getting into first principles territory. The short version is that the gantry being on a cantilever and an open frame means it's going to act like a tuning fork under toolhead acceleration. Higher resonance limits toolhead acceleration before print quality nose dives.

I haven't seen any accelerometer graphs posted for an XL, but it doesn't take much more than opening up PrusaSlicer and finding maximum accels set to 3k to see the direct result of that. That's where the rest of the community was 4-5 years ago. There's a reason why Prusa has an entire blogpost making excuses for why their printers' performance numbers aren't up to snuff compared to modern designs (while also cherry picking comparative numbers)[1].

It's not my only complaint about the XL but it's the most obvious one. I haven't been impressed in general with the prints I've seen come off those machines.

[1] - https://blog.prusa3d.com/original-prusa-printers-now-printin...

>Goalposts moved!

I'm not the one who set that goalpost and I disagree with it because it's nonsensical. The market is not a binary between a $1000 Mk4 and a $200 Ender 3, period.

>You must mean high-end China, yeah? $2k doesn't sound like much when it comes to FDM high end.

No, I'm talking about hobbyist builds. Yes, you can drop a couple of orders of magnitude more on industrial printers but I was under the impression we were discussing the consumer space, unless you'd like to move those goalposts?

>Are you thinking that Prusa printers are a "hobbyist journey"? Because they're definitely an appliance. Not only that, they're an appliance that can be repaired with off-the-shelf parts for the most part.

That's not what I was saying at all. I was saying that if you're after the hobbyist journey, dumping $1k into a Mk4 doesn't make sense. That's money better invested in something that will ultimately be a better printer.

If you're after the appliance experience, the Mk4 is a worse option than a Bambu would be.

>While it does hinder them competing on price, it also grants them some flexibility to improve designs over time. Since the printer has printed parts, users can print the new/better designs if they want.

This isn't mutually exclusive.

Bambu has made revisions to the parts they send out of the factory. End users have made extensive modifications like the excellent Hydra AMS.

Being flexible doesn't mean locking yourself into low volume, expensive production.

>don't require any manual tuning by the user (just like Prusa.)

Not just like Prusa. Better than Prusa does. The machine calibrates itself for EM and PA for any arbitrary filament. This is a large part of the "produces better prints" equation.

>What about contributions to the 3d printing community?

Their slic3r fork is the basis for Orca Slicer, which has become my preferred slicer on non-Bambu printers.

>What about repair?

Bambu provides detailed repair guides for the entire machine in both text and video format:

https://wiki.bambulab.com/en/x1/maintenance

>What about support (and I'm not talking about Prusa's chat/email)?

Nearly every part on the printer is directly available on Bambu's webstore and reasonably priced.

>Or will they instead want you to buy a whole new printer to get the latest whatever that they've lifted from the community?

Long term support remains a question mark but they've made promising first moves on that front. The P1 series have seen a number of upgrades since launch and the firmware for the X1 continues to receive significant firmware growth -- a completely new motor calibration routine got pushed out this month, for example. It's an unknowable at this point.

Jo wrote an entire blogpost about it:

https://blog.prusa3d.com/the-state-of-open-source-in-3d-prin...

One of the big takeaways from this for me is that Jo doesn't really understand IP law. He talks about wanting a new license for open source hardware; the trouble with that is that a copyright license does not and cannot protect a hardware design. That's what patents do.

That's not a defense of current IP law, just a statement on the reality of what it is.

The gantry is on a cantilevered open frame.

This is something that the hobbyist world recognized as a really bad idea a long time ago because it makes the machine fundamentally less rigid than a well-supported closed frame would be.

Lack of rigidity results in higher vibration which results in lower quality parts and limits the speed that you can run the machine at. Prusa has tried hard to frame this as them prioritizing quality over speed but that's absolute marketing bullshit -- the things that allow a printer to run fast are largely the same things that allow it to produce high quality parts. A fast printer simply has a higher ceiling and while a fast printer can run slower if you need it to, a slow printer will always be slow.

Jo's said explicitly in interviews that the choice to use that frame design is because he wanted to prioritize easily being able to see and remove completed parts from the print bed.

>On the XL: the 0.6mm makes sense with the build volume, to significantly improve print times, but seems to really not work well with the 5 toolhead models, and introduces massive amounts of zits, stringing, cross-contamination, etc.

More fundamentally, the XL uses an open frame design specifically because Jo wanted to prioritize being able to easily see and remove prints.

The entire gantry sits on a cantilevered open frame -- that's a fundamental engineering failure that's going to mean the XL will always be slower and produce lower quality prints than closed frame designs.

>If you give an absolute beginner an MK4 and an Ender 3, they're going to use the MK4 every time. It's vastly less effort to get started and the QC of one vs the other isn't even a competition.

The actual market isn't Ender 3 vs Mk4.

It's extremely hard to argue that Prusa printers represent a good value in any market segment in a post-Bambu world.

>What makes them "much, much better" ? Initial cost of ownership and what else?

They're cheaper and produce better prints faster without requiring any manual tuning by the user.

I'm a hobbyist. I own multiple high end printers that I've dumped $2k+ into. They're fantastic machines that I enjoy tinkering with.

But I've also got an X1 for when I just want a part and don't want to think about it. It's an appliance. It just works. That has massive value for people where printing is a means to an end rather than a hobbyist journey.

If you're a hobbyist that wants to tinker, there's nothing that justifies dropping 5x the cost of an E3 on a Mk4. $800 will go a long way toward making up any difference.

Or just go all-in and build any of the full hobbyist designs that will be a far better printer than a Mk4 anyway.

>And yet, they can't make printers fast enough.

Because they refuse to engineer their products for mass production. Which is, coincidentally, one of the reason why they're also failing to compete on price.

I think what he's actually misinterpreted are complaints that the Mk4 controller board isn't open source.

Prusa has long bragged about their hardware being open source and they've made an about face on that over the last couple of years.