Hacker News new | past | comments | ask | show | jobs | submit | lelandbatey's comments login

Being an economic powerhouse or not isn't required for the idea to be a reasonable and workable one.

But given the high levels of dysfunction/conflict that led to the breakup of the country, I doubt they'd meet whatever bar you set for "economic powerhouse".


> the high levels of dysfunction/conflict

Doesn't sound like Yugoslavia had a successful model.


The conflict was due to it being a federation of several culturally quite different nations. When Tito died, the politicians that replaced him started heavily pushing nationalist ideologies amidst the 1980s economic crisis (which was not limited to Yugoslavia).

PS. You're arguing with people who lived there. How can you be so certain you know better than those of us who saw it first hand? And I'm in no way saying it was a perfect system, btw.


If you had lived in then you should know the standard of living was poor. More then a million people left to work in Germany as Gastarbeiters to send money home. Gas was limited. Common goods had to be brought through the border with Austria or Italy. Inflation was crazy, everybody bought German Marks the same day they got their paychecks, otherwise the money was worthless by the next day. What happened to you if you were caught as a political opposition in Yugoslavia is a story on its own.

> You're arguing with people who lived there.

You're using the past tense. Is that intended?


I want versioned docs literally always. I am basically never on the _most_ recent version of a software package, so being able to pick the version of the docs that matches my actual version is genuinely not negotiable.

I never want to "pinpoint changes", I want to avoid documentation totally irrelevant for the version I actually use. Here's a real world example:

Redis.io doesn't let you look up docs for any version but the latest version. The URL for docs has "latest" in the path, but swapping that for a version number just 404s. Let's look at the EXPIRE redis command and how it interacts with HSET, in the context of using Redis to cache some data with a TTL. https://redis.io/docs/latest/commands/expire/

HSET means setting a field of a hash (object/dictionary/map) to a value. EXPIRE means setting the expiration (TTL, time before autodelete) of a particular thing in redis. You can set the expiration for an entire hash in redis, but not for individual fields of that hash. HSET is like an upsert by default; it creates the hash in redis and then populates the given field with the value you set. In your application, it's pretty reasonable to want to have an operation which is like an HSET as an upsert which also sets a maximum expiration time on the parent hash, but only if there's not an expiration time set. Looking at the docs for EXPIRE, you might note that there's a special option you can set which does this exact thing, the NX flag. Thus you can implement a simple "sharded-by-hash upsert with a maximum TTL" by doing an HSET followed by an EXPIRE NX. Great!

Except that is not true! You cannot do that! Read all the paragraphs you want, you won't find this critical note unless you scroll aaaaaalll the way to the bottom of the page, past the "Differences in Redis X.Y.Z", past the Appendix, to the very last little section called "History", which isn't about the history of this page, but is instead a single bullet point of critical information noting the following:

    Starting with Redis version 7.0.0: Added options: NX, XX, GT and LT.
Redis 8 released this month, Redis 7.0.0 released in April 2022. Some version of Redis prior to 7 (6.4) will be explicitly supported by Redis the company till August of this year. I encountered this particular hiccup much further back when it was very reasonable to still be using Redis 6.X

In such a case as this, I desperately wish that I could have clicked a little dropdown and chosen docs for Redis 6 instead of Redis 7, because this caused a serious problem as hashes just weren't expiring at all. It was especially bad because the Redis clients would send those command options to the server and the server would silently drop them, so everything looked completely fine except that the hash keys were being perpetually moved forward and never expiring!

Please version your docs!


As the person that wrote such documentation, I respectfully disagree, I understand you point but I want to tell you why I believe the way it is, is better for Redis. Redis is a system that is 99% backward compatible across all versions combinations: Redis 2 was released more than 10 years ago, and this is a very hard to find case where things are not perfectly backward compatible, but still in a case where the Redis 2 semantic was so odd to be avoided in most tasks. Now, in a system like that, to have man pages that tell you the differences among versions is much better than versioned documents where you would require to diff yourself among the different pages. In a single document you know all the behavioral history of a particular command, that often is just: "always as it used to be", plus features that are backward compatible entering newer versions.

I think a changelog on the page is key, as you say. I also think that having versioned docs does not requires us as users to do diffs manually, that's what a changelog/history is for. Ideally, I'd like to have both: all docs are versioned and all docs have "history" sections.

I think Google's got something going wrong with their usage limits, they're warning I'm about to hit my video limit after I gave two prompts. I have a Google AI Pro subscription (came free for 1 year with a phone) and I logged into Flow and provided exactly 2 prompts. Flow generated 2 videos per prompt, for a total of 4 videos, each ~8 seconds long. I then went to the gemini.google.com interface, selected the "Veo 2" model, and am now being told "You can generate 2 more videos today".

Since Google seems super cagey about what their exact limits actually are, even for paying customers, it's hard to know if that's an error or not. If it's not an error, if it's intentional, I don't understand how that's at all worth $20 a month. I'm literally trying to use your product Google, why won't you let me?


Something you can consider are "dentist office screen mounts". They're what they seem like, arms like you'd see at a dentist office/hospital that swings around an entire room, to hold a light or screen. See this example Amazon listing for one that mounts to a wall with a 5foot swing area: https://www.amazon.com/DW630-1218-Long-Articulated-Adjustabl...


This doesn't seem like an "all or nothing" take. This person is trying to be clear about their claims, but they're not trying to state these are the only possible takes. Add the word "probably" after each "then" and I image their intended tone becomes a little clearer.


I really can't speak highly enough of Trino (though I used it as AWS Athena, and this was back when Trino was called Presto). It's impressive how well it took "ever growing pile of CSV/JSON/Excel/Parquet/whatever" and let you query it via SQL as-is without transforming it and putting it into some other system.

What an impressive feat of engineering.


Yeah, the Eastside is a real estate hellscape. Everything east of Lake Washington till highway 203/18 is genuinely quite bad. I had cheaper rent on top of Queen Anne, 1 block from the Trader Joe's, than any place of comparable walk/transit on the east side ($2065/month for a 2 bedroom 1.75 bathroom apartment+1 parking place, ~950sq/ft).


Why stop at WA-18, though? I-90 is wide and not particularly busy past that point even at peak times, so you can easily get to North Bend in only a few more minutes.

The real cutoff point for commuting to Seattle is just past exit 34, because that's where they close Snoqualmie Pass when there's too much snow.


Really curious what would amount to 1.75 bathroom, I'm unfamiliar with the concept. One full bathroom and a second with just a a toilet/sink combination?


That is 1.5. A 1.75 is usually a small bathroom with a shower. The space would have no room for a tub. These often get counted as full baths anyways.


Yeah. A lot of us prefer a shower to a bathtub with shower anyway. But it's probably an important distinction for people with kids especially.


I don't think that's quite true, as competitors like Kagi have been able to compete well with effectively zero clickstream (by comparison). It'll help, but it's not the make-or-break that the index is.


I think a click stream isn't necessary, but Kagi is not a good basis for the argument in my opinion.

Kagi is a primarily meta search engine. The click stream exists on their sources (Bing, Google, Yandex, Marginalia, not sure if they use Brave). They do have Teclis which is their own index that they use, and their systems for reordering the page of results such as downranking heavy ad pages, and based upon user preferences (which I love).

https://seirdy.one/posts/2021/03/10/search-engines-with-own-... is a source I would recommend checking out if you are curious.


Kagi sends searches to other providers (Bing?) and then simply re-ranks the results, so they're effectively inheriting the click stream data of those other providers.


Alternatively, just lie about the cancellation reason. *"Why are you cancelling your Comcast internet service?" Answer: "I am moving to the Solomon islands, where there is no Comcast service or business for 1000 miles in any direction (at least)."


“I’m going to prison and getting my affairs in order” is a good one too.


If you want to be adversarial, tell them you're converting to the Amish faith, and would they like to hear details about it?


If cost can be anything, does Anubis implement such a system then, by using proof-of-work as the cost function?


Sort of. Anubis is frontloading the cost all at once and then amortizing it over a large number of subsequent requests. That detail is what's causing the issue when browsing with additional privacy measures.



Can't see, that page is protected by anubis.


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

Search: