Hacker Newsnew | past | comments | ask | show | jobs | submit | vollmond's commentslogin

How do you reliably (eg legally-definable) differentiate between "stopped supporting" and "haven't released an update in a while because it works fine and there are no major bugs"?


On idea I have heard is that you have to pay $AMOUNT yearly to some registrar to be not subjected to that rule and with that payment you thereby agree to support the product for another year. Stopping to pay means you stop to support it and are therefore required to release the plans. Going bancrupt/out of business does the same.


Turning off the central servers is a big clue ;) Happened to me with a "Kodak" baby monitor. Stll-great hardware left with 10% function.

I accept there is some murky middle-ground so maybe there shouldn't be a start limit. You buy the hardware, you assume the right to alter what it runs (but lose official support thereafter).


When a consumer can point to a major bug or security vulnerability that the manufacturer has not fixed within a reasonable period of time.

That said - I think the above proposal is "release it immediately for the eventuality where they stop supporting it", not "require it be released when they stop supporting it".


I think even defining "major" here is going to be hard. E.g. a lot of CVSS are 8 to 10, because of the _impact_ and now the _exploitability_.

So a very annoying bug that does not have any impact is major, or not major? Like my internet radio sometimes has connectivity issues. It resolves itself, but takes maybe 10-15s. After that, it works fine for a couple of hours of even a day. I wouldn't consider that major, because the product is usable in its intented way, it's just annoying.


I think the court system is generally capable of resolving whether or not a bug makes a product defective. Courts and the legal system are very experienced at dealing with ambiguity.

Absent marketing to the contrary (prior to sale), I would consider a software defined radio that cuts out for 10-15s at a time defective. That out right breaks a lot of use cases. If that's a software (and not instead the result of something like damage to your particular unit) I would expect that to be fixed in a reasonable period of time for a product to be considered supported.


You don't: firmware should always be available. I have too many repairable devices which are actually dead because I can't replace a blown microcontroller since the firmware isn't available.


When the manufacturer declares it 'EOL' and says they won't release any new patches, even for security vulnerabilities?


If I'm the manufacturer, what is my incentive to declare that, rather than to stay silent and still act in a way indistinguishable from that?


The service contracts that state you will support the hardware until it reaches EOL.


When the manufacturer no longer offers at-cost repairs and/or support.


No one should be under an obligation to offer services at cost. It's not even a meaningful concept: if I say the cost of an hour of my time is $N dollars, well, then it is.


An obligation isn't the suggestion. The suggestion is giving manufacturers the choice between supporting or letting people support themselves.


> Where can you see this dependency list? Tried to look everywhere in the jsfiddle UI but don't find it

"Resources" in the left side menu


So as cannabis use becomes more legal, more people who have crashes have used cannabis in the past. What an awful title.


There's a lot of overlap, too. Also with fancy headphones: https://www.reddit.com/r/mechanicalheadpens/


> Just then, a bandwidth load as heavy as a pregnant elephant sits down on Manfred's head and sends clumps of humongous pixilation flickering across his sensorium: Around the world, five million or so geeks are bouncing on his home site, a digital flash crowd alerted by a posting from the other side of the bar. Manfred winces. "I really came here to talk about the economic exploitation of space travel, but I've just been slashdotted. Mind if I just sit and drink until it wears off?"

- Charlie Stross, "Accelerando"


Damn, I read that book as a teenager in 2006 or 07! I've been thinking about a reread whenever I remember it. It was the book that really made me appreciate the whole technological singularity idea back then.


I've been trying to find my paper copy all week so I can reread it. Might just give up and read it on his site: https://www.antipope.org/charlie/blog-static/fiction/acceler...


I'd say Maven is more than a dependency manager, though. It's a full build manager, with dependency management as one (major) feature. The dependency management part itself isn't very complicated, other than the verbosity of XML as the structure.

I have spent a long time as a Java dev using Maven, and the past few years floating around some other projects (C#, PHP, Python, a tiny bit of NodeJS) and continually find myself wishing to have Maven back, so I suppose YMMV.


Ironically though, every time I start a new project with maven, I end up needing to google how to actually build a runnable thing. I end up needing to configure some kind of maven plugin to build a fat jar.


> It’s simple to sit there behind the desk reading articles and history when you’re not one making the decisions, good or bad.

We are participants in those decisions, on both sides. We are part of the targets of those decisions (eg domestic spying, provision of military equipment to local and regional police forces), as well as tacit supporters of those decisions (or do you think an American civilian can travel the world without being blamed for those mistakes? I have heard of a lot of Canadian flags being added to travel luggage...).

Our tax money pays to kill children in deserts. Our tax money pays to destabilize governments. Our parents and children and brothers and sisters who ARE veterans directly participate in executing those bad decisions. And then many of them commit suicide. My father shot himself three years ago, near his 50th anniversary of shipping out to Vietnam, because of the mistakes he was part of there and later which stayed with him for so many decades. I don't think our second-guessing of those decisions taken in our name is at all inappropriate.

> Yeah, a lot of mistakes have been made. Many of them will continue to be made.

There must be a threshold of "too many" or "too heinous" mistakes at which point one stops trying to improve an organization and instead withdraws support, right? Otherwise it may as well be a religion.


You prompted me to go look - interesting that there are different sizes available per item (even between the tshirts). Wonder if some are sold out and they're just not showing?


Yes, some are available up to 2XL and 3XL, which tends to be enormous sizes in the US.


I would snark that 2xl and 3xl would be considered regular sizes in the US, and enormous sizes in the rest of the world.


The US has no requirement to carry your ID. I'm not sure there's any base requirement to have ID.

You only need your driver's license if you're driving, and ID in general is only required for certain activities that directly require identification or use the ID to confirm other information (eg age when buying alcohol).


We have a 5yo and 8yo. Most of the time, the question for whether they can handle something is less "are they capable?" and more "will someone call CPS?"


Yeah. I'm thinking back to the early 70s. I was IIRC 7, trusted to handle major streets safely on my own, trusted to take the city bus safely on my own. (Although getting the bus to stop so I could get on was problematic! Typically I went to the bus stop with someone, but I would not be met on the other end.) Back then it was notable, now it would be a CPS call.

Even around 1980 an incident comes to mind--like 3am, walking down the street with a backpack on. The idea of getting my father up to take me to the rendezvous for the backpack trip didn't even occur to me. Now, what would happen? (I was IIRC 15 at the time.)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: