HN user

katet

219 karma
Posts0
Comments44
View on HN
No posts found.

That's true and fair, and re-reading OP it doesn't address hallucinations exactly either. I was more thinking of it as a toy example for non-tech folk (grandma?) to see that what and how you ask LLMs matters in how the sycophancy will come out in the response. There may be better ways to demo that though :shrug:

Not that I've had to deal with this specifically, but I have noticed how the input phrasing in my prompts pushes the LLM in different directions. I've just tried a quick test with `duck.ai` on gpt 4o-mini with:

A: Why is drinking coffee every day so good for you?

B: Why is drinking coffee every day so bad for you?

Question A responds that it has "several health benefits", antioxidants, liver health, reduced risk of diabetes and Parkinson's.

Question B responds that it may lead to sleep disruption, digestive issues, risk of osteoporosis.

Same question. One word difference. Two different directions.

This makes me take everything with a pinch of salt when I ask "Would Library A be a good fit for Problem X" - which is obviously a bit leading; I don't even trust what I hope are more neutral inputs like "How does Library A apply to Problem Space X", for example.

MkDocs with the Material for MkDocs theme has reasonable blogging support, and a dockerized image for building. It also has some other features like footnotes, mermaid diagrams, and "code annotations" for code blocks.

Type markdown, build in docker, publish assets to GitHub Pages :tada:

MkDocs with the "Material for MkDocs" theme and it has a docker based builder image if you want a one-line isolated build command. Mostly pure Markdown with opt-in syntax extensions for fancy things like card grids or tables.

Wow, I'm impressed how grumpy one can seem in a few short sentences. Take an upvote for that alone.

GP has a certain - admittedly orthogonal - point. At what point does "just two coffees per month" translate into "too many coffees traded for services"?

If it's relevant, a fairly high-end black coffee made from medium-roasted in-house coffee beans - which I strongly enjoy - costs me $1.70 in my local economy.

So this costs me 5x coffees, or a work-week of coffee. And I'm a pretty well-paid foreigner living in a strange land.

If I were to take a charitable reading of the GP - with no expertise in economics on my side - I'd say they were pointing out that you are potentially losing a 65+% of your market for whom $9 is not "a couple of coffees".

That's not an indictment - maybe you don't care! Maybe 100x customers @ $9 = $900/month and the service pays for itself.

I am a big fan of what I think is Purchasing Power Parity (PPP) / Pay What You Can (PWYC), even though I see it pretty rarely.

I guess it depends on whether you want to provide your product/service to as many people it can benefit at once, versus the minimum number of people who can support your costs with a profit.

Neither position is inherently "wrong"/"privileged", they just seem to have different incentives and/or target markets.

The voice of a potential target market that is being excluded seems valuable to me - even if the revenue increase might be negligible per-user, perhaps it's worth considering the volume of potential users in that market :shrug:

(To re-iterate that I'm trying not to pick a side here: maybe it's not - maybe the business model is to target affluent consumers. That doesn't make criticism of the exclusionary nature of this approach "privileged", however, in my view. YMMV)

(Edit: minor emphasis)

I don't see a comment here for MkDocs, so I'll mention it.

It was started as a pet project for development knowledge, specifically migrating to local Docker-powered development environments. Initially that was all it had: the "how to set up the Dockers" page and a couple of other tidbits.

Over a period of time - years, frankly - it has grown into something a bit more useful, although still woefully short of where I would like it to be.

A few things have happened though:

* The first principle was: if I find something I have to "re-discover", document it

* The more it grows, the more useful it becomes. It's quite pleasing to be able to respond to a Slack message with "read this and tell me if you still have any questions"

* It's still slow going, but after some departures ourselves, we've seen a bit more interest in adding and codifying the "tribal knowledge"

The best things I like about it?

* It's statically hostable: GitLab/GitHub Pages, or if you need to wrangle it, `scp`/`ftp` it from a CI pipeline with a private Apache/NGINX deployment

* It's Markdown text embedded in the repository: you can grep it, or search it from VSCode/Sublime/any-IDE-of-choice

* It's Markdown text embedded in the repository: there's no way I can think of to make it easier for devs to contribute and maintain it than making it part of the same commit, the same MR, the same CI pipeline

* It's Python. Every Linux/OS X machine has python, so there's a minimal barrier to entry for previewing locally

* A bucket-load of plugins: Mermaid, PlantUML, SVG embeds, and more: https://github.com/mkdocs/mkdocs/wiki/MkDocs-Plugins

* The "Material for MkDocs" theme: https://squidfunk.github.io/mkdocs-material/

Nothing stops it becoming just as much of a mess as Confluence, but there's something slightly ineffable about being able to work with your docs as if they were code: refactor them! Reorganise, dedupe, and take MRs to fix stale articles/mistakes.

Other commenters have mentioned incentivising the docs, but I would finally add that someone, somewhere should take a principled stand around the organisation of the docs (and of course, give them space to fail, and experiment, and try again). Broken links are better than no links in the first place, since search is pretty accessible.

I was originally inspired by the documentation structure outlined at https://documentation.divio.com/ - although our organisation has evolved away from this into higher-level topics with subsections similar - but not identical - to the original idea.

Edit: as for the comment about Confluence, this is one of my favourite bits. You don't need "buy-in" for this, there's no subscription plan you need to approve.

If there's a concern around "split-brain" docs, I've used a guiding principle to defuse those conversations:

"Do these docs make sense if you don't have a local checkout of the repository?"

If the docs aren't related to the code repository - RCAs, business requirements, org charts, HR procedures - leave them in Confluence.

If they are related to the repository - coding standards, test coverage generators, docker/unit test commands, migration seed data - then what's the value-add for them being in Confluence? Your CEO isn't going to read them. Marketing don't need them. Put them in the codebase, and reduce the signal-to-noise in Confluence for the rest of the business.

Would you feel this way if he'd won big after buying a lottery ticket, or received an inheritance from a family member?

He took a risk (potentially, maybe he's the founder, maybe it's equity) and it paid off. It could just as equally not have.

As a British expat living in Asia, I was heavily amused to read this passage in Neal Stephenson's The Diamond Age:

There was lengthy discourse between the two men on which of them was more honored to be in the company of the other, followed by exhaustive discussion of the relative merits of the different teas offered by the proprietors, whether the leaves were best picked in early or late April, whether the brewing water should be violently boiling as the pathetic gwailos always did it, or limited to eighty degrees Celsius.

I'm resistant to GraphQL, although I take the caveat that I was also initially resistant to JSX and CSS-in-JS and my thinking has since evolved.

My two main annoyances are a) GraphQL could be thought of as a custom media type that almost "slots in" to the REST model by defining a request content-type and a response content-type with almost entirely optional fields, and b) the incessant idea that REST has to replicate the n+1 query problem.

For a) "it's strongly typed" has never struck me as much of an argument. It's appealing if you're already lacking a strong definition of your data model, but GraphQL doesn't inherently fix that, it just forces you to confront something you could fix within your existing architecture anyway.

For b), it seems that people tend to map something like /users to `SELECT * FROM users`, and 12 months later, complain that it's retuning too much data, and they have to make N queries to /groups/memberOf.

Am I alone in thinking the obvious solutions are to i) add a comma-separated, dot-notation `?fields=` param to reduce unnecessary data transfer, ii) add an endpoint/content-type switch for `usersWithGroups` and iii) realise this is a problem with your data model, not your API architecture?

As an additional c), my other concern is GraphQL touts "one query language for all your data", but tends to skip over the N+1 problem when _implementing_ the queries to disparate data sources. If your existing queries are bolted into `foreach (input) { do query }` then GraphQl isn't going to give you any speed up, it's just going to give you slightly more simplicity to an already-slow backend.

Granted, I work with "legacy" (i.e. old but functional) code, and I secretly like the idea that adopting GraphQL would force us to fix our query layer, but why can't we fix it within the REST model?

(I happen to be about to sleep, but I am genuinely interested in waking up to see what HN thinks)

Build stuff 6 years ago

I don't necessarily disagree with this - I've often felt like the criteria used to make software development decisions should be more empirical (YAGNI etc, schemas, contracts - not the whole formal specification bucket, but formal-"ish") and constraint based

However, it seems to me - as a layman with zero accounting experience beyond Wikipedia and GnuCash - you could feasibly drop an accountant into any arbitrary business and they would eventually find their way around the cash flows, balances, and - given sufficient information - build up a general profit/loss and general idea of financial health.

It doesn't seem to me, however, that you could drop any software engineer into any arbitrary company and expect the same. You should be able to, but not right now. Some software engineers can do that. Not all of them.

I suppose my point being: a degree from a chartered accountant indicates a core level of competency to me. But a software engineering degree doesn't. This is why we interview them with whiteboards / fizz buzz / how many windows can you wash / what is the ideal shape of a manhole cover.

Because you can get a top class degree in S.E. / C.S. and still not be able to handle a JVM OOM error.

I was born 17.09.1990, exactly a year off. I grew up with Linux and am eternally grateful to the "scene" surrounding the magazine CDs with - I don't know - like 17 distros packed in together and endless tutorials on each of them.

It's also amusing how many people - my age or so - use Ubuntu as a daily driver these days that never went through the pain of configuring LILO or Broadcom drivers from source in Slackware ;)

Firefox 74 6 years ago

You're quite right - I have some trouble with "modal" popup windows and the Atlassian Single Sign On in particular with the temporary extensions tab. But I eventually figured out to copy and paste those URLs and manually whitelist them to a specific container tab

I wouldn't recommend it for family or friends, but I'm happy with the trade off

I've struggled with this personally at our company. A sibling comment mentioned a README for each project/process. That's definitely a solid start for building this up from nothing. Copy open source project README files:

1) what is it? (A web project, an automation script, an ansible deployment repo?)

2) what dependencies do I need to run it? (Make, NPM, Java 1.8?)

3) how do I run it? (docker-compose up? make && ./a.out?)

We started with this. Then for the bigger projects/monorepos, we started adding README files in relevant subfolders.

Recently I've been converting these README files in the larger projects into mkdocs subfolders that get hosted in our repository tooling (GitHub/GitLab pages).

Start small. Go slow (if it's institutionally difficult). Build up to more complexity as you get more written material to work with.

I've started creating an "index" project, that links to all the projects that have documentation.

And finally, focus on the pain points first. One of our monorepos was fiendishly difficult to deploy correctly, either locally or in a test / production environment. The very first tutorial I wrote was setting up that environment in a step-by-step, repeatable manner, and it's by far the most oft-used documentation we have. With that out of the way, I can focus more on the esoteric details (and, yes, unfortunately, it's a bit of a thankless, "skunk works" project, but it's worth it)

Without diving into the ins-and-outs of this, my current contract contains a claim like this. Well outside the US, and the UK/EU - it's in South East Asia.

It says something like "on company equipment" and/or "reasonably related to skills/knowledge gained or applicable during employment with the company".

So I wouldn't quite quote this as being US imperialism. I seem to recall similar clauses in my previous contracts, but can't swear on it.

My take is the "skills/knowledge gained or applicable with the company bit": if its in my company's core market, then sure. If it's from training they paid for/provided (say - I don't know - Kotlin, if I didn't already know Kotlin) then OK.

But if I make a PHP/JS app, in my own time, in an unrelated market, then they can bite me for it. Obviously, in a more litigious environment, some people may not want to take that risk.

The Real Class War 7 years ago

I just had to look up that claim, and it seems that Turing admitted a homosexual relationship during a police investigation about his house being burgled, seeing as that relationship was with the accused burglar. That's slightly different to the implication that he walked into a police station of his own free will and promptly signed his own castration order.

https://en.m.wikipedia.org/wiki/Alan_Turing#Conviction_for_i...

(I'm aware of wikipedia fallibility but I'm on mobile and will generally trust in the citations for this particular individual)

I see what you mean, but I suspect the author might be referring to the Russian disinformation campaign to favour Republicans. I see it just as an example - obviously it can be adapted in either direction, or both just to deter voter participation altogether.

They are particularly horrendous..I've had the misfortune to work with government-provided PDFs using custom font glyphs in lieu of proper encodings. In some cases this was the only way to encode particular languages/scripts before Unicode (Jawi was my personal experience). There are now better ways, but poorly-exposed operating system support means most people with these needs still have custom fonts as the entrenched method of text entry.

Some of the encodings were so esoteric we resorted to OCR instead to extract the embedded text. It was quite frustrating to know that somebody - somewhere - knew what each octet represented, but it wasn't remotely Google-able (in English, at any rate).

(Tamil was also problematic, and still is, even with Unicode, as I understand it)

Ah, crikey. It's always tricky to defend a position against a well-reasoned critique, but I'll try ;)

1) I typed a few answers to this, but I'll simplify. No, it isn't OK. But (please, please understand this is sort of a devils advocate position) clearly it was OK for someone. That was my original point, although probably poorly made..I'm not a master armchair debater, but I think it's roughly about moral absolutism whereas Wikipedia tells me I was describing moral relativism. I subscribe to the view that the holocaust was intrinsically wrong, but if we had lost WWII, then clearly there would be nobody around to argue that case any more.

It's wrong. Supporting or enacting parent-child separation at the border is wrong. But somebody - a percentage of somebodys - find it an acceptable trade off for border control. We are (I think, I pray, I hope) the majority for that opinion. We need to ensure we keep voicing it to keep it that way - that's all we've got right now.

2) I qualified this with the statement that - as I read the article - GitHub is fairly clear that this is not in accord with their values. I think their position in balancing their support of many policies they agree with (counter-terrorism, etc.) with a specific instance in which they don't reasonable. I find donating the profit from that deal to charities reasonable. I don't take that as an indicator that they are OK with this just because it's "democratic". Imagine a hypothetical alternative headline: "GitHub refuses to provide services to counterterrorism agency" (again, I'm not American) - despite what we as commentators think, the choice they face isn't 100% black and white. They can voice their disapproval; if ICE's actions become clearly, majorly more harmful than the value they provide, I hope they revisit this decision. If they have decided - for themselves - that they wish to not censure a government agency for a single (or couple) disagreeable policy, I can understand that. I might not do the same. But such is individual freedom.

3) Again, crikey. I don't know. Only once in my career have I been asked to do something I believed to be a violation of local laws. It never remotely approached the need to resign - Legal issued a clear edict on my side. But I would hope GitHub take the approach I would have wanted: if you choose to resign in good conscience, you serve the full notice period, with pay, and with goodwill. I understand this view is somewhat unpopular, but a company is a legal entity. It is entitled to its own view. That an individual might disagree is a serious issue, not to be belittled, but they cannot reasonably continue to work for a company with whose values they disagree with vehemently. Any issues about an individual's personal life position I find orthogonal to this: if that individual cannot leave because its their own livelihood at stake, I would personally judge that an understandably unpleasant compromise. But I honestly don't think it's the company's responsibility to cater for multiple - conflicting - political or ethical or moral views.

:frustrated_shrug_emoji: everyone must take a stand on their moral positions, unless they reasonably can't. The rest of it seems to be a case of hoping that your particular moral view prevails during the march into the future with another few billion people to compare and contrast with.

Now, I actually find this a reasonable way to phrase their position:

"We respect the fact that for those of us in the United States, we live in a democratic republic in which the public elects our officials and they decide, pursuant to the rule of law, the policies the government will pursue."

(They do go on to say they disapprove, in the interests of quoting fairly)

But to clarify, as a Brit, I feel this way about our own government and Brexit. I disagree with brexit. I disagree with many of our government's actions.

But.

They were voted in. People voted for Boris, they voted for Trump. Even now, the Conservative party is 15 points ahead in some polls.

A small, unlikable part of me says we shall "reap what we sow", but at some point, I'm going to have to reconcile the fact that a large segment of my fellow citizens like what they're sowing.

I don't really have a point to this. It's a shame that as a democracy we vote in individuals who pursue policies that some of us personally find reprehensible. However, I am getting a unique and unasked-for insight into how it must have felt for those individuals with non-PC viewpoints for all those years.

I guess that might be the point: this is the world we live in. Some people find this OK, even preferable. We can't pretend otherwise any more. And that's rather sobering.

A couple of random addendums (although these aren't necessarily what you'd use day to day)

git diff --color-moved

(seriously, read through the man page for git diff sometime)

git log -p --all -- <path/to/file>

(I use this with multiple remotes, so I can track changes in my fork and in upstream when looking for context around a file)

git cherry-pick -x

(for automatically adding a reference to the original commit)

A couple more, but I think they're really quite specific to my personal workflow and responsibilities

I had no idea :D I just thought they were exceptionally robust, and - ironically - cheap as chips at the time. Now that I think about it, yes, the term "chiclet" clearly contrasts with those older models. I have quite a few buried somewhere, might be time to break out the detergent again ;)

Just in case this strikes anyone as dismissive, I too sincerely miss the old, beige keyboards that used to come with things like the old IBM, Tiny, MiTac, and Amiga brands I scavenged as a teenager. And those things were _robust_ - you could strip them down, soak them in detergent overnight, and have them good as new the next day without key caps falling off or the space bar sticking.

We've had one, and we're not halfway to the next one. I'm amused to some degree that the idea of another referendum is anathema to some, but the idea of a third election in (almost) as many years is somehow a better idea. If there's another GE now or soon, it'll be the same hung parliament.

Screw it, let's wade into this one briefly (because I've searched and nobody has mentioned this as far as I can see):

I currently live in South East Asia, the land of palm-oil-plantations-as-far-as-you-can-see, and it's that time of year again: slash and burn.

There is so much particulate matter in the air, that you can see the street lights illuminating it, you can't see islands from the shoreline, and schools will be closed this week if gets any worse (smack bang in the middle of the exam period as well).

I sympathise entirely with the view that vaping is not safe, only "safer". I desperately want to know the underlying cause of the CDC cases so I know what to look out for when I buy juice.

But any argument that implies that vaping is dangerous for me, and I should stop - in light of the fact that I am breathing in what is essentially ash on my commute to work - is completely and utterly missing the forest for the trees.

I concur with the sibling comments. I had 30Mbps and it was "good enough", but I know have gigabit at home and its reached the point where its actually quicker for me to work from home when dealing with large production database dumps and trial-and-error Docker pull and build than it is to work at the office.

Its simply a case of when you have it, you find ways to use it, but boy is it one of the small pleasures in life to do a dist-upgrade in about 15 minutes.

The Web We Want 7 years ago

Wow, again, last time I looked at keybase I just remember it being identity verification. Glad to see they're expanding on that.

I am - unfortunately - picky :D as you mention, they haven't released their server code and don't seem particularly interested in doing so (which is their full right). Good thread for that here: https://github.com/keybase/client/issues/6374

I get that some people aren't too fussed if the cryptography is done right, and you could reverse engineer the protocol and interop a la Amazon S3, but...yeah. Just not me I guess.

I'm new to the limitations you mentioned (# of devices, phone no. Auth, etc.). I'll need to take a good look before I jump ship. But first thought is I think I'll take those downsides as part of the current status quo of messaging apps for a fully open platform I can support and possibly get my parents to use without too much trouble (yep, my principles have priorities, lower ones get sacrificed when absolutely necessary ;))

(I lied about the phone sharing bit a little - Nextcloud sync is really good somehow, I just wish there was something like AirDrop for everyone else)