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

If some business is defensively buying off all the competition, that’s an easy ATM for a serial entrepreneur, especially if the large business is price gouging: found a competitor, grow it e.g. with some like-minded funding, sell it at a premium. Wait for the clauses of the contract to run out, and rinse and repeat.

The defensive acquisitions can work on domains with gravity effects to a degree, but those are domains are far from being the total market.


> found a competitor, grow it e.g. with some like-minded funding, sell it at a premium. Wait for the clauses of the contract to run out, and rinse and repeat.

Unrealistic, that strategy has no history of success. MariaDB tried... still wimpy.

> The defensive acquisitions can work on domains with gravity effects to a degree, but those are domains are far from being the total market.

Not so. Market size and inertia, connections, red tape and political weight are always present, fundamental forces of "gravity". They are the total market, at least the part of it that matters.

More importantly, even if your strategy of "feeding the machine for personal gain" did work, it amounts only to feeding the machine without changing its nature or direction. That strategy can benefit few individuals but it can't fix any of the issues discussed here.


Complex systems are difficult to predict or reason about, especially in turbulent times, and when only partial information about the world is available, and only part of it is accurate. Nothing new under the sun. If you’d always know what’s going on, you could categorically beat the market or make central planning to work flawlessly.


Well, it’s a medication designed for diabetes (the weight loss variant has a higher dosage and different brand name, Wegowy or so), and for diabetes the usage is, by default, permanent. Unless it is replaced by other medication or if the lifestyle changes make the insulin resistance not be an issue any more.


The unfortunate side-effect is also that as US does not honor guarantees given in the Budapest memorandum, no country is going to give up nuclear weapons trusting contracts, and that European nation states (and possibly Canada, Mexico) will draw the conclusions on how to best get functional security guarantees ie. have own nuclear stockpile. This has been the status quo USA has bought by being a security provider, and by betraying it the downside is to returning to the nuclear armageddon scare of the cold war — if a European country nukes Russian territory, the retaliation might well bite back to the US soil. If Europe got too cozy with conventional warfare capabilities, the US got too cozy with the idea that they’re providing security out of the goodness of their hearts instead of it being a geopolitical bargain where they receive certain advantages as well.


IRC <3 Still daily driving it with some friends. I wouldn’t be surprised if my Discord chat history was unavailable in a decade, so IRC is a nice option to run on the side. There’s value in simplicity, and I admit the risk of sounding like a tech hipster.


IRC has no chat history either, right. I get the simplicity of IRC but searchable history is a bonus for Discord. As long as the service is available, searching is kinda possible. With irc you have to find out which bot provides history, which is then usually split over multiple files


My client dies the logging, and I can e.g. grep decade old logs. I’m not sure if you can get same level of access to Discord logs (=export them). I guess Discord bot that logs everything as a historian is a partial solution (I guess log bot cannot catch DMs).


I sort of feel the same…but on the other hand if you consider ”delete from” exists also, it’s not completely unsensible to consider you first tell what operation you’re about to perform to the data. Would be nice to start with the source entity name for sure. Dunno what ”select 1” would look like, I guess the from foo would be optional.

Random saturday ramblings, sorry about that :-D


DELETE FROM is even worse. Accidentally/mindlessly press cmd+enter before you wrote the WHERE? Poof, data gone. Make it FROM … DELETE!

I also wish we needed to explicitly take locks. In PostgreSQL at least (I think other dialects/engines too), figuring out what operation will take what lock and potentially mean downtime is left as an exercise to the reader. Force me to write WITH EXCLUSIVE TABLE LOCK when I add a non nullable column with a default!


If you're going to run commands that modify data directly on the cli, do it in a transaction so you can roll back. Also, start with `--` to make it a comment. Once you have the correct query and someone's checked your work, go back to the beginning of the line and remove the `--` so you can run it. It's also a good idea to write a select * or count first to check that things make sense, and then start your transaction, go up and modify your select into a delete/update, check affected rows looks good again, maybe do another select or two to check that data looks like you expect, commit.


Fun fact: if you still have a MySQL (MyISAM) database, the transaction commands return success but don't actually function, so you can't roll back.


Well, to be fair ”from foo delete” would do the same I suppose :-D Unless there’d be an explicit end to the statement to designate you really want to delete everything. Which might not be a bad idea. Or make ”where …” mandatory and bring in ”delete_all” or ”delete everything from foo” as a syntactic guardrail. This is equally implementable, whichever the order of ”delete” and ”from” would be.


The MySQL client has an --i-am-a-dummy flag that won't let you run a DELETE (or UPDATE, I think) without a WHERE.


the Google SQL variant has where required for deletes. on my first encounter of it I was just like "huh, neat", you can always use 1=1 as the predicate if needed.


If you don't SELECT first before running the DELETE query, you shouldn't be anywhere near an IT job, let alone a production database.


Good tools prevent mistakes from happening rather than blaming the user for using it wrong


Probably an unpopular opinion, but as an Apple user it is okay for me to pay 30% extra (which I often do instead of using Android and getting certain apps for free), so I avoid having to sideload Epic/Facebook/whatnot stuff from their own mandatory app store + having the hassle of figuring out if there's a subscription model and how difficult it is to terminate, how to handle refunds, what darkpattern analytics are included in the appstore binary etc. etc.

If you need certain amount of money per user for the product to be profitable, raise the price to account for Apple's cut. But please do not force me to install app stores from companies which have their lifeblood in data brokering my life. At least I have an understanding with Apple that if they go haywire with that stuff (like it was close with the whole CSAM scanning debacle which damaged my trust in Apple and I started considering alternatives) they will lose my hardware purchases as well.


This is such a common talking point, the "hassle of side-loading app stores and the insecurity of trusting them (for permissions enforcement)," that I wonder if some PR firm out there was hired and this talking point is showing up everywhere so people subconsciously think it's consensus and start parroting it themselves (why I'm now seeing it and responding)! The application security model is at the OS level and not the app store level (which is really just a dressed up branded package manager, and has been done forever in GNU-land).


I like to think this via car analogy: you have similar ecosystem with car infotainment system platforms, but there the cost of switching is often minimum tenfold. Game consoles are an analogous platform to phones with similar pricepoint in switching costs. Of course phones are much more present in our daily lives for the most part of the population. But I suppose the similar burden would easily hit those platforms if legislation would be imposed, and it would come with both upsides and downsides depending on one's viewpoint.


In 100k years there’s much less need to process it anycase, the waste is very front-heavy in its radioactive harmfulness. Of course it’s still chemically harmful later on, but it does not differ from other heavy metals and is leagues better disposed of than all the lead, cadmium, arsenic, and other such stuff we have laying around (which does not decay at all).


We do have large peat reserves (AFAIK some estimates compare the total amount to Norway’s oil reserves), but usage of peat has been decreasing/phased out for climate and environmental reasons.


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

Search: