Lazare

Tried Obsidian for a while, loved a lot about it, but....mmm.

Obsidian out of the box is a bit limited; plugins are great and add tons of features, but then you start hitting issues with plugin maintainers abandoning plugins you rely on, or needing to make a decision between three different plugins that all do the same thing slightly different. Depending on your use case and expectations that may not be a big deal, but I really missed not having what I personally saw as core features not being officially supported.

(Also, FWIW, the sync service is a bit pricy for what it is. I get that it's how they're trying to monetise it, but...I would have preferred another pricing model, even if the total cost was just as high.)

I've personally switched to Trilium Notes which I'm finding nicer. One element I particularly like is that it has first class suport for notes being able to exist at multiple places in a tree simultaneously. I know it's a very personal thing, but for me personally being able to file notes in multiple locations "clicks" in a way that tags didn't.

Trilium Notes: https://github.com/zadam/trilium

And here's a nice writeup on ways to use Trilium (although much of it applies to Obsidian too): https://github.com/zadam/trilium/wiki/Patterns-of-personal-k...

This is how https://aider.chat works; it gives you answers in the form of git commits that include the prompt and a description of what it did.

It's an interesting UX.

I spent a while trying to install and run this but it never worked. Seems like it might be an interesting tool.

I've had more luck with https://aider.chat although for whatever reason I haven't found it useful enough to actually use.

Interestingly the article actually calls out the 4Runner as "among the most reliable models in the survey". Apparently the newer model years are still pretty solid!

The linked article is pretty explicit about how they calculate it. A detailed explanation is literally the first section.

And as they explain, they ask people about the actual problems they've had in the last 12 months with their car; nothing soft or fuzzy or relative to expectations at all.

PBEM (Play By Email) was (and maybe still is) a big thing in the wargaming space. Long, long ago I was part of a group on USENET and later IRC that organised games of Stars! (https://en.wikipedia.org/wiki/Stars!) with typically a cadence of a few turns per week, or sometimes "blitz" games played onn IRC with several turns per hour.

Quite fun, but needs a community interested in such, and very focused game design. (Specifically, need lots of meaningful decisions to be made each turn, but relatively few turns in a game.)

Stars! was one of many such games back in the day, but I'm pretty sure they're all dead now.

Paying for GPT-4 is worth it.

ChatGPT Plus is one way of doing so and works fine. There is no 50 per month limit; not idea where you got that from. The limit is 50 per 3 hours, but I've honestly never hit it.

You can also just get an API key and use it that way via a number of different tools, wrappers, and frontends. Depending on your use case, that may be better or worse.

I have grave reservations about AI art, but...nope, that doesn't follow.

It's true that there are a lot of (human) artists in the US. (Something like 80 million, broadly defined.) And it's also true that the art and media each artist views shapes the art they create, including art and media we see quite incidentally - graffiti, ads on bus shelters, paintings in the hallways of office buildings. And in the course of the year each of us will view thousands upon thousands of such pieces of art and meida.

So if we had a licensing scheme such that every artist had to make a non-negligible payment to the rights holder of every bit of media they view, then artists, collectively, would be liable for hundreds of billions of dollars in royalty payments. 80m aritsts * 1k pieces of media * $5 license fee is $400b; that's just basic math.

This calculation is, very obviously, not an argument that all art is theft. It's just some math about a hypothetical licensing scheme, and that's all a18n were doing too.

You may think (and I'm inclined to agree) that a human paging through an artist's ArtStation profile is fundamentally different than an LLM using it as training data, but that's an argument not addressed by a18n in that quote.

For anyone curious what's going on here:

You can't carbon date human activity, you can carbon date the point that organic material stopped growing. If you carbon date some partially burned wood found in the remains of a fireplace, then you can be pretty confident the fireplace was built around the time the tree the wood came from was cut down. And the better you can prove that what you found was actually a fireplace and that the sample actually came from inside it, the more confident you can be that the date you got relates to human activity.

If you just dig a hole in the ground, find some organic material, and carbon date it, you can be pretty confident that there were plants growing in the area in the past, but that's all you've discovered.

Guess which approach to carbon dating was followed here?

There's basically zero evidence presented that the pyramid was constructed 16k years ago, but they have made a strong case that there were plants growing in Indonesia 16k years ago. ...not that this was ever in any doubt, mind you.

> Thus far, it remains undetermined, as things are still in progress.

My question was, do you think the 3rd circuit got it wrong, and that the spin off didn't have access to that money when it initially tried to file for bankruptcy? That is not in progress, and we have as much information as we ever will have. J&Js finances, the text of the funding agreement, and the text of the 3rd circuit's opinion are in the public record!

> The entity that J&J spun off has attempted multiple times to declare bankruptcy, only to be thwarted [...] they stated that "the time was not right" and questioned the amount of funding.

Right, they were thwarted because they had TOO MUCH money. The time wasn't right because with an $60b+ blank check from J&J, they weren't bankrupt. Which is a pretty plausible argument!

> LTL re-filed for bankruptcy three hours after this ruling. (Why, was the time right, in the afternoon?)

This is hardly a mystery. They refiled with a different (and less generous) funding agreement, which (rather obviously) brought them closer to being technically bankrupt but (as the 3rd circuit ruled) didn't come close enough.

> Georgia Pacific did the same with Best Wall

Can you provide any support for this claim? Because I think you've got the sequence of events backwards - specifically I believe they promised $175m in the initial funding agreement, and then later raised it to $1b, which (so far) they haven't walked away from.

Happy to learn more about the details though.

> St Gobain did the same thing

Again, what did the original funding agreement promise, and what did they deliver?

> When only four firms have tried this

I am legitimately curious - have any of those four firms failed to deliver on the funds promised in the funding agreement of the spun off holding company? Because I'm not aware of this occuring, and some quick internet searching didn't come up with any results either.

I mean...the 3rd circuit ruled that J&J did fully fund the spin off's liabilities - or rather, that the spin off had access not to "a couple of hundred million", but to at least $61.5b.

In that specific case, are you suggesting that the 3rd circuit got it wrong, and that the spin off didn't have access to that money?

Well, fraud, obviously. :)

Beyond that, you can still, in theory, make a lot of money being a supplier to a low margin business. By some estimates NVIDIA booked over $2b in extra revenue due to crypto.

Kagi is great if you're willing to pay. DuckDuckGo is...okay if you aren't.

Yes, although if you think about it a bit:

With a VPN you're hoping there's no logs at all, and it's pretty easy for a VPN vendor - entirely by accident - to keep some logs around. And then a search warrant lands, they look around, find the logs, and the promise is broken. And it's entirely possible for that to happen by accident. So if I pay for a commercial VPN that claims they don't keep logs, I'm gambling on their honesty and competency.

With a search engine you're hoping they don't bias search results to favour advertisers, sell your search results to advertisers, etc. And that's not something you can really do by accident. If Kagi is being honest, then they're not accepting money to modify search results, nor are they logging my searches, or building up a profile of my searches, or modifying seearch results based on that profile, etc. Even if it turned out Kagi goofed and really were logging all my searches and tying them to my payment account (maybe, eg, for perfectly innnocent reasons, like solving a bug), that doesn't actually change their value proposition to me all. They're either super evil and lying about everything they're doing, or they're fine, even if it turns out they're cutting a couple of corners.

Kagi is putting themselves in a position which is inherently easier to trust than a VPN vendor (or early Google), due to the nature of the business model.

Yes. Quite useful. Also groups listacle spam ("top 10 X" type articles).

A fair call, but to quote their privacy policy:

> Unlike "free" search engines, we do not log searches or in any way tie them to an account.

So if you trust them to do what they say, then yes, that pretty much solves the issue. If not, well...

Just chiming in here. My experience is:

* Google search was good, but has been steadily getting worse. Over the last 1-3 years it's become actively unplesant.

* DDG solves a lot of privacy issues, but the search quality is strictly worse than Google. I know people who use it preferentially, and I respect that, but personally Google search is already so bad than opting for something even worse is hard for me to accept. And I think almost every DDG user is familiar with having to fall back to Google to get a result.

* Kagi solves the privacy issues and the search quality is excellent - certainly better than Google is today, and subjectively, feels as good at least as good as Google was at its heyday. And notably I have never needed to fall back to Google; it's just a strict upgrade. I absolutely feel it's worth the cost.

I can't really predict if it will stay good; some of the decline in Google is no doubt just because they're the most popular SEO target, so it's possible if Kagi becomes wildly popular it'll be a victim of it's own success. And of course, Kagi's goals and principles may change with time, etc.

But as of today, if you think you might get some value from really good search, and Kagi isn't wildly out of your price range, give it a shot.

UUIDv7 is a nice idea, and should probably be what people use by default instead of UUIDv4 for internal facing uses.

For the curious:

* UUIDv4 are 128 bits long, 122 bits of which are random, with 6 bits used for the version. Traditionally displayed as 32 hex characters with 4 dashes, so 36 alphanumeric characters, and compatible with anything that expects a UUID.

* UUIDv7 are 128 bits long, 48 bits encode a unix timestamp with millisecond precision, 6 bits are for the version, and 74 bits are random. You're expected to display them the same as other UUIDs, and should be compatible with basically anything that expects a UUID. (Would be a very odd system that parses a UUID and throws an error because it doesn't recognise v7, but I guess it could happen, in theory?)

* ULIDs (https://github.com/ulid/spec) are 128 bits long, 48 bits encode a unix timestamp with millisecond precision, 80 bits are random. You're expected to display them in Crockford's base32, so 26 alphanumeric characters. Compatible with almost everything that expects a UUID (since they're the right length). Spec has some dumb quirks if followed literally but thankfully they mostly don't hurt things.

* KSUIDs (https://github.com/segmentio/ksuid) are 160 bits long, 32 bits encode a timestamp with second precision and a custom epoch of May 13th, 2014, and 128 bits are random. You're expected to display them in base62, so 27 alphanumeric characters. Since they're a different length, they're not compatible with UUIDs.

I quite like KSUIDs; I think base62 is a smart choice. And while the timestamp portion is a trickier question, KSUIDs use 32 bits which, with second precision (more than good enough), means they won't overflow for well over a century. Whereas UUIDv7s use 48 bits, so even with millisecond precision (not needed) they won't overflow for something like 8000 years. We can argue whether 100 years is future proof enough (I'd argue it is), but 8000 years is just silly. Nobody will ever generate a compliant UUIDv7 with any of the first several bits aren't 0. The only downside to KSUIDs is the length isn't UUID compatible (and arguably, that they don't devote 6 bits to a compliant UUID version).

Still feels like there's room for improvement, but for now I think I'd always pick UUIDv7 over UUIDv4 unless there's an very specific reason not to. Which would be, mostly, if there's a concern over potentially leaking the time the UUID was generated. Although if you weren't worrying about leaking an integer sequence ID, you likely won't care here either.

When people say something is a ponzi, they generally mean that they think it's deceptive, fraudulent, or otherwise unsavoury. They don't mean that it's literally the sort of scheme made infamous by Charles Ponzi.

I think there's value in using precise language, so I reget this usage, but it's common whether I like it or not.

I agree with your overall point, but I would note that US security regulation focuses heavily on disclosure as a mechanism to protect investors, and the owners of pre-deal SPAC shares are not well protected in that regard.

It's good that they get to decide if they want their money back; it's bad they they're required to make that decision with so little information.

> SPACs, in theory, democratized access to late-stage private markets, aiming to give retail investors an early seat at the table.

I question how that's even true in theory. A SPAC is an elaborate (and expensive) mechanism to bring a private company public with less disclosure; even if it works as designed, you're not letting retail investors invest in early stage companies.

> He mentioned that the allure wasn't just the capital but the perceived simplicity of the process, compared to a traditional IPO.

There's very little simple about a SPAC, which suggests the founder may not have understood them as much as he thought he did. Perhaps he meant easier?

Also, I mean, there is a simple process for going public that does at least partially democratize the process: Direct listings. I've always found it fascinating how unpopular they are.

I feel like the moderation culture of Stack Overflow became toxic and counterproductive years ago. It's like the worst parts of Wikipedia, but squared. Just endless arguments over what is or isn't a duplicate or is or isn't relevant, while every interesting question somehow ends up closed, good answers are downvoted, and spam drifts to the top.

I'm sure everyone involved actually wants the site to be useful and pleasant, but somehow the actual result is the exact opposite.

That being said, I don't think the culture or moderation has got worse recently, so I suspect the traffic decline is either a change in Google's algorithms or the impact of ChatGPT (or both).

ULIDs work, but:

The spec has a really weird choice in it - it attempts to guarantee monotonicity. There's a few problems with that, namely that it's almost entirely pointless, it's impossible to actually guarantee it, and the spec mandates it be done in a bad way. Breaking those down:

* There's no particular reason why you'd expect UIDs to give you monotonic ordering, and no particular use case for it either. Being roughly k-sortable is very useful (eg, to allow efficient DB indexes), but strict monotonicity? There's just very few cases where that's needed, and when it is, you'd probably want a dedicated system to coordinate that. Even worse, if you do need it, ULIDs don't actually guarantee it. Which brings us to:

* UIDs are generally most useful in distributed systems, and the more you scale the more that will become required. The second you have a second system generating UIDs, your monotonicity guarantees go out the window, and without work that the various ULID libraries have not done, that's even true the moment you have a second process generating them. And the ULID spec doesn't even try and work around this (nor do all ULID libraries try to guarantee monoticity even when used in a single threaded manner), which in turn means you have no idea if any given ULID was generated in a way where monoticity is being attempted.

* The actual ULID spec says the UID is broken up into a timestamp and a random component, and if you ever generate a second ULID in the same millisecond, you must increment the random component, and if you can't due to overflow, generation must fail. Which is wild; it means you can only generate a random number of ULIDs per millisecond, and there's a chance you can only generate one. Even worse, if you can ever manage to cause a system to generate a ULID for you in the same millisecond as it generates one for your target, you can trivially guess the other ULID! Many use cases for UIDs assume they're effectively unguessable, but this is not true for compliant ULIDs.

The ULID spec is, a best, a bit underbaked. (And as others have noted, I find that Crockford's base32 encoding is a suboptimal choice.)

I agree; base58 or base62 (which KSUIDs use) have a lot to recommend them. Crockford's base32 works, but I don't love it.

My first choice would be to just use type-prefixed KSUIDs, which gives you 160-bit K-sortable IDs with base62 encoding, which works great unless you need 128-bit IDs for compatability reasons.

Doesn't help; what matters is your total R&D spend which - apparently according to current guidance - includes all/most of programmer salaries.

If you spend is going up, you're pre-paying more and more tax on profits you haven't earned yet. If your spend is constant, you'll stay the same amount behind. If your spend declines you'll start to catch up, and if it drops to 0 and stays there for ~4 years you'll catch up to where you would have been without the law change...but if you start spending again you have to start pre-paying again.

If such things interest anyone, here's some relevant Wikipedia links:

https://en.wikipedia.org/wiki/Ithaca_Hours (one of the larger systems, and the one Kootenay's was copied from, now defunct)

https://en.wikipedia.org/wiki/Local_currency (a general name for such currencies, with a list of a bunch of different ones)

https://en.wikipedia.org/wiki/Time-based_currency (not all local currencies are based on time but Kootenay Barter and Ithaca Hours were)

Although interesting, I should probably note that as a general rule, they have never seen high adoption, aren't very clear about what problems they're trying to solve, and seem to have minimal advantages over, well, any other solution. Even in places where a local currency system is nominally operating, you generally have to look very, very hard to find anyone participating (or indeed, who has even heard of it).

Also, the Kootenay currency has been defunct for something like 15-20 years.

No, hilariously Buzzfeed News was top tier investigative journalism, and at their best was as good as anything done by NYT or WaPo.

The business model seemed to be "what if we have truly great investigative journalism, funded by clickbait listicales that we, inexplicablly, use the same brand for".

It's easy to mock the branding decisions they made (and not entirely unfair) but it's still a loss to the internet to see them go.

> I don't know of any jurisdiction (apart from the US, apparently) which allowed 100% non-amortized tax credit for loosely defined R&D salaries.

This is not about tax credits, this is about whether salaries are an expense. If Widget Inc makes and sells a bunch of widgets for $100m, and then they pay $20m in rent, and $30m for materials, and $40m for salaries, with $10m left over, with no other complexities (eg, interest, depreciating factory equipment, etc.), then is their profit this year:

1) $10m (or maybe a bit less, if they got any tax credits)?

2) Some other larger number closer to $50m?

You'd be hard pressed to find many jurisdictionns where the answer isn't option 1. I certainly don't know any offhand.

No.

After 5 years the first years salaries are considered to be a "finished" R&D project, which means there's nothing left to amortize.

The only thing like that is that if, after a few years, you fire all your devs (or at least, all devs working on adding new features and building new products), then you can keep amortizing the last 4 years of salaries for your now-fired workers over the next few years, which reduces your tax base. But I mean, by that point, who cares? Any software business that has fired all its devs is over.

> it makes total sense to me that an "off the record" chat doesn't need to be preserved, even by a court order to keep all records. Let's assume there is a chat app that is officially designed to be off-the-record,

You cannot officially designate anything to be "off the record". That's just not a thing that the legal system recognises - the closest thing might be attorney-client privilege, and that's not relevant here, so none of your analysis applies.