A common trope that is probably ignored or even unknown to uninformed C/C++ programmers, is that -Werr should be used for debug builds (as you use during development) and never for release builds (as otherwise it will most probably break compilation in future releases of the compiler)
You mean shorter than `https://tiki.li/run/`? That one only works after the real URL is loaded at least once. The un-shortened URL was huge as it contains the whole app in base64 encoding or some such
Sometimes I dream with a wishful solution like defining areas of "great living desirability" (basically the cities where seemingly majority of people compete to live in), and charge a yearly tax of N% the market value of each home (with crazy high N, like 20), for owners who have more than M units in that area (with a convervative M, like 3 or even 2).
...You'll see how greedy investors flee fast, and the remaining buyers are honest people who don't want to speculate, but to actually own a home where to actually live.
But this model introduces an incentive to artificially bump the major version ASAP so as to be able to charge again for updates. One way this happens is with feature creep, to justify a new version every few months. A "done" application wouldn't reasonably get a new major version ever, so the software becomes ever-growing and then bloat ends up happening.
There is the counter-incentive that people won’t upgrade if they don’t think it’s worth it. What you describe doesn’t usually happen, in my experience.
>A "done" application wouldn't reasonably get a new major version ever
Did that company not want to make money? Even if they want to pretend their software is done, there is incentive to just change the name, add a new feature or two, and maybe poke at the UI so it looks different enough to be a definitely new product that you should buy and not mostly the same as last time.
I read the license and of course IANAL but it seems clear that Debian, Arch, Guix, F-droid or any other independent signed reproducible build channels can package and distribute their own reproducible builds of this software, as long as it is "free of charge for non-commercial purposes", isn't it?
(a FOSS license would also work, but if I have learned something in HN before, is that don't FOSS if you ever want to make money from something while preventing others from making money off of it)
And Debian is OK with that, because Debian is not a for-profit company that paid it's developers money to make a product, thus they don't care that others get it and resell it.
For a company, the product itself, what makes money, cannot be OSS, as it makes its resell value effectively zero. If the software was OSS, then the software is _not_ the product, but added values are (support, consulting, etc... the classic trope)
But if the software itself wants to be the product, and is created by devs who require their monthly salary, typically the question is between a non-FOSS license or it not existing at all to begin with. Not between a non-FOSS and a FOSS license.
> For a company, the product itself, what makes money, cannot be OSS
It can. I work for XWiki SAS, and we sell some extensions under LGPL at store.xwiki.com. And it works, people and especially companies, choose convenience over installing the tools to compile and install the extensions themselves. It works because it's usual and easy to understand for companies to pay for software, and way easier to justify than donations to sponsor free software.
There are also several open source Android or iOS apps that you can buy. OSMAnd+, Conversations, DAVx⁵, Amaze Tools, Fair apps and are/were examples of this
Thanks for your perspective! It is interesting. How does the business plan deal with the chance that it's perfectly in my hands (read: on anyone with whatever motivation, usually commercial) to grab the code and provide the same thing but cheaper or even free?
In this case I feel that the answer might ultimately be that it works because it is mostly a niche market and there are other value adds such as support from the makers themselves, which is always a good thing but already is not the software itself per se.
I don't think many companies would be confortable with such a brittle grasp on their sales. Basically it relies on nobody else wanting to do the same (and maybe risk that they execute better).
Imagine if Photoshop was OSS... well, it is good food for thought.
(EDIT re. the apps you mention: also interesting cases; not sure how much that model is actively hurting them or otherwise helping them, would love to see writeups from the companies or creators)
> How does the business plan deal with the chance that it's perfectly in my hands (read: on anyone with whatever motivation, usually commercial) to grab the code and provide the same thing but cheaper or even free?
Here, it is just some extensions that are in a repository that is enabled by default in the main product (which is free and open source). Someone forking would not have their repository enabled by default. They could of course distribute their own version of XWiki itself with their repository enabled by default.
The extensions we sell also come with some basic support, so there's also that. At some point, if someone forks and sells for cheaper, they'll also need to provide the fixes and the features asked by their customers, at which point they'll not be able to keep up with cheap prices.
I suspect a former colleague who now works as a freelance might be distributing some of these apps to their customers (they contribute some fixes from time to time through pull requests).
I guess if it happens more largely we'd figure something out. Now, it's also not our main income. You might be right that it's niche enough to fly under the radar. Forking and maintaining a cheaper copy might also not be lucrative enough: the apps we sell answer needs of existing customers anyway, so we need to write this code anyway, but someone external would probably find something more lucrative to do with their time. I don't know :-)
Another good example I didn't think about in my first comment is WordPress extensions with their premium plans. Because of the WordPress license, you are forced to distribute your WordPress extension as open source. And this is probably less niche, for the biggest extensions.
I was pointing out that Debian can't distribute software that is licensed "for non-commercial use only" because Debian doesn't have use restrictions, and so their users might be engaged in commercial use.
This is the point number one in their free software guideline,
> the current possessor might have acquired the product bona fide and is not necessarily the thief. In order to assess this, you cannot repurpose the product yourself, but need the cops and court involved.
A fun thought experiment is that in the time you might have left your car parked in the street, it might be stolen, sold bona fide, then (by happenstance) parked in the same area, so one day you just go back to it and drive it away.
I guess in a more practical sense, you could claim that's (more or less) what happened after recovering your possessions after having them stolen... what would happen in that edge case?
I worked with a 3rd party library that had this mentality. "A bug is a bug so the assert fails and thus the code is now in an unknown state thus The right thing to do would be to ABORT the process execution immediately". Oh my.
Just do "if (pointer)" and when that fails, error out from the smallest context possible that applies to that pointer, and nothing more than that. I.e. the real BEST thing to do is to abort the current connection. To skip the current file with an error. To fail writing that piece of memory. Whatever. But never abort (unless maybe in debug builds).
The end result of this library was that we had a WebRTC server handling 100s of simultaneous video calls, and then when a single new user tripped up during connection and went through a bogus code path, the library would decide "oh something is not as I expected so I'll abort, of course!" and the whole production server was brought down with it.
That kind of behavior does not help achieving high production quality and providing robust and reliable services.
We ended up removing the library's runtime assertions, which meant that connections that would bug the library code would just end up failing with an error somewhere else, that could be used to just discard the attempt and try again. All in all, numbers showed it was a huge positive in stability for the service.
I think the original comment was more directed to scenarios where the precondition fail is let slide, NOTHING happens, and that's not the desired behaviour, so you have a bug. Such code exists too often and it's just poor quality.
If there's anything I've learnt about error handling, it's that it must be approached with very careful consideration of what you want the app to do (conceptually) when the error occurs. Sometimes that's crash the program, sometimes it's throw an error, sometimes it's log and move on. The issue comes when devs don't want to think about this, whereby the simplest solution is absorb any error and forget about it.
Agree with your assumption, but then I also know that developers often read recommendations and convert them into dogma, ignoring the specifics for when those recommendations should be applied.
Early in my career I taught programmers and I was horrified to come back to one client and find they followed my advice, but not where it applied meaning that what they did was actively harmful.
Ever since that, I realized when a developer makes a recommendation they need to be very explicit about when it applies otherwise they are doing more harm than good and hopefully someone will publicly challenge their recommendation to bring their unstated qualifications to light.
- Fix the actual bugs
- Provide super visor and isolation as a protection mechanism and resiliciency.
What you've now done is to essentially just hammer it quiet while sweeping all the issues under the rug and pretend everything is great when the library is actually in ill defined state. How's that possibly any better? You're probably experiencing hard to detect bugs, occasional runtime corruptions and all the fun stuff now that you'll likely never be able to fix :)
"That kind of behavior does not help achieving high production quality and providing robust and reliable services."
It absolutely does.
When bugs are obvious and caught early they're easier to fix and this leads to higher quality more robust and reliable service.
Pretending that everything is good is never the solution.
I agree with you. But with a product trying to gain a good name and its first loyal customers, a crash that brings down the complete service is a no-go, no matter the excellence in software development that one seeks theoretically.
Bugs won't be fixed either if the early customers fly away.
In practice, ignoring the bugs meant better numbers. Only the user connections affected by those bugs would fail, which then a retry system transparently solved. This is how the library should have worked to begin with.
Bugs are always going to exist, it's the first law of software, that there is no such thing as a software without bugs. So no, I don't believe on aborting a whole application is ever an acceptable behavior for a library. Do the if(pointer) else return error, not the assert(pointer) else abort.
I'm sure you made the best judgement call given your circumstances. Of course from business perspective software quality is irrelevant. It's best achieved by letting the PR/marketing team take care of it.
However, the problem is that when you start with this route that you allow buggy/incorrect code to continue running you cannot reason about your program anymore. You cannot make any smart decisions when the program is allowed to continue after hitting a bug.
If I call function "foobar()" and I assume it's buggy but it continues and leaves my program in a bad state what should I do? How can I determine that the result that foobar() produced is garbage?
So maybe foobar() returns a bool/success/flag value that indicates that it bugged out. But then what? Maybe I want to log this as an error but what if the logging function also has bugs in it? So maybe the logging function didn't work as intended because I called made a bug when I called it when trying to deal with the bug that happened inside foobar(). How do I propagate this error correctly without introducing more bugs to my callers who then must all do something.
The fact is most programmers can barely get the "happy path" right. Even normal logical error conditions ("file not found") cause plenty of software to fail because it cannot do proper error handling and propagation. So if you let incorrect code to keep on executing nothing good will ever come out of it and there's 0 chance anyone will be able to write correct code on top of incorrect code.
The point is once you start writing code to "deal with" incorrect logic its like trying to do math after a division of zero. None of the rules apply, none of the logic applies. Your program state is random garbage.
All these problems disappear when you make the simple rule. You don't write code for bugs. Simply just abort.
Mind you from the library perspective what is your bug might not be a bug from my perspective. In other words if I provide a library for random 3rd parties I can assume they will use it wrong. Therefore their buggy code is what I must expect and return some error value etc. But if I'm calling code that I wrote from my own code I don't write a single line of code for bugs. I simply assert and abort.
And to your last point of bugs always existing. Yes I agree, and the best we can do is to squash them as soon as possible and make them loud and clear and as easy to debug as possible (i.e. direct callstack / core dump). Not doing this does not fix them but smply makes them harder to fix.
> That kind of behavior does not help achieving high production quality and providing robust and reliable services.
Right, so since it's the messenger (assertion) that brought news of defeat in battle, you kill the messenger instead of trying to win the next battle.
Your problem is that the entire business seems to hinge on a single point of failure - if the server binary dies, you lose customers. This has nothing to do with what some library does or does not do, it's just a horribly designed system.
That crash should have made you all stop and think real hard about what you're doing because clearly it's not working:
1. Don't write bugs in the first place. No I'm not kidding. Your tests clearly suck so fix them, make sure you do proper PR reviews, make sure to leverage your type system to the fullest, use all available tooling, etc.
2. Design your system be resilient to the server binary dying because I assure you, there's nothing you can do to prevent it from happening for one reason or another.
I just got a Pixel Watch 3 and find it impossible to understand how they have such an advanced monitoring on so many health aspects, including sleep cycles, but it doesn't support Smart Alarms (aka. Smart Wake or similar names), i.e. an alarm that is able to wake you up when you are in the lightest phase of sleep.
(just like what Fitbit bands themselves had, or what apps such as "Sleep as Android smart alarm" try to guesstimate)
That's weird. The fitbit bands that Google still sells do have that. They seem to be having a really hard time making the fitbit acquisition work in many ways so I guess that's not surprising.
> I just got a Pixel Watch 3 and find it impossible to understand how they have such an advanced monitoring on so many health aspects, including sleep cycles
The Fitbit integration with the Pixel watches is not great. The Fitbit support is even worse - it actually makes Google's support look decent by comparison, which is really saying something.
Hmmm, that's strange? I have it installed on my Pixel 8, which launched with Android 14 and recently upgraded to Android 15. I wonder what's different for you?
reply