HN user

mgreenleaf

247 karma

Founder of yakware.com

Posts20
Comments72
View on HN

Even after reading the Wikipedia article [1] I'm a bit confused what the relevance is, unless it has to do with Christian pacifism, but even then it would be nice to have context of some sort.

And I had no clue this site existed, but Anabaptist World news has no exciting news related to anything tech [2] (though that is kinda expected).

[1] https://en.m.wikipedia.org/wiki/Schleitheim_Confession

[2] https://anabaptistworld.org/latest/

I use it for servers because of the stability. For me, that's the key differentiating factor. I set a server up and it will keep running indefinitely, with easy sysupgrade, syspatch, and updates. I haven't had that same experience with Linux servers. Rock solid foundation with ease of use and administration is great.

I work with the KDE virtual desktops grid with a 3x2 arrangement and wrap around on a 32" curved screen. I've found it very useful to put the same windows in the same grid squares and have hotkeys to easily go between. I know exactly the keystrokes ahead of time to get to the window I want and don't have to move my neck to get there. I can tile them, since I've got plenty of space on the one large screen, but usually the 6 virtual desktops are good enough. I've tried multiple monitors before, but couldn't get into it.

I triple boot; there are things I can only really do on Windows with full support (commercial art programs, Unreal Engine), but for software development and general usage Linux wins hands down; even the ability to switch out a wm and have it customized for my workflow is a major win, and the command line utilities and environment aren't even comparable. My third is OpenBSD, since I run that on my servers.

Use the best tool for the job.

Document generation from Word Templates (yakdocs.com) & stripe analytics dashboard w/ SQL queries (yak-mu.com), both use Kotlin on the JVM w/ Java WebToolkit (https://webtoolkit.eu/jwt) because of familiarity, kotlin's expressiveness to share components & so that everything is written serverside; OpenBSD as the base operating system because of simplicity and good defaults.

OpenBSD 6.9 5 years ago

I run a lot of OpenBSD servers using either only base (httpd + pf + relayd) or base + software I write with minimal dependencies. The security in base is excellent for that. I don't have a desktop environment on my servers. It is easy to upgrade these, and I get very good security & configuration. So, for my use case, having "no remote holes in the default install" is exactly what I want and need. YMMV.

I think it depends very much on the data being modelled.

Certain situations might call for a timestamp instead of a boolean, especially if it is a value that is only ever turned on once and never turned off, possibly `user_deactivated_at`; I do prefer having a bit field and a separate timestamp for things that can flip; and for a lot of use cases it is good to just have a full event stream implementation where you can construct the state at any point in time and you get events data combined with the timestamps.

I’ve argued before that this is because the difficulty of building tools depends more on the complexity of programming languages (which are extremely complicated; just see C++) than on the idea, and that, until this changes, no tool can arise without enough sales to pay the large fixed cost of building it.

Language servers helped with some of this. You can write a standard language server that does a very good job and pool the talent of the entire community to add small useful features, instead of having to write a new implementation even if you just want to create a new editor.

Just the other day I saw a comment on HN about wanting something like the whytool, as well as having a way of seeing whether a function has any possible path of being called to/from the current function. Those are very useful features, but would require a large platform of language analysis to build on.

It would be nice if language servers had that as a supported feature, but seems like a difficult problem to solve. The naive approach would be to store every mutation in memory and where in the code it happened, but that might have horrific memory and performance considerations.

For the ancestor/descendant checks, the naive approach would be to have a recursive "find usages" check that checks if it ever hits the target, but, again, going anything past a trivial number of recursions could have an explosion in memory usage and time cost.

Fossil Chat 5 years ago

If you already have a chat infrastructure set up with all the bells and whistles, then you probably don't need this; it is a different kind of workflow.

But one workflow for it would be open source projects that prefer not to have to maintain additional infrastructure and just want to inline ephemeral communication w/o having to keep it forever; then they make a design decision and have everything that is finalised moved over and documented in the wiki.

Fossil Chat 5 years ago

I think the idea is so that core developers have a quick way to chat with one another over design ideas w/o needing to register or setup other infrastructure, then move the best over to the permanent forum record or wiki.

Then the core members don't need to have a dedicated channel somewhere else. If they did, then that would be another inbox to check; instead they can check the fossil chat when they are on the project site looking over commits or documentation.

So it is just another source of information on the main "fossil channel" instead of another channel to check. Viewing it in that way, it is reducing the number of channels by simply inlining it.

Fossil Chat 5 years ago

I use it for most of my projects, with git covering the rest of them. I prefer the cli usage, philosophy, single binary / single file repository, and having all the notes/issues transfer across when I push makes it easier to develop and test across windows/linux/bsd. Autosync and other things are well-thought out details too; generally feels well designed. Otherwise, day to day usage isn't much different.

It feels like going back one or two hundred years is, in some ways, even more of a cultural shift than going to another country is today. I come across gems all the time that are products of the times and deeply insightful. Which happens with interacting with other countries today too. Both are profound and in similar, but different ways.

I love moments like this where two people meet and share information about a shared thread in their lives, when they would otherwise probably never know. Good job hacker news:)

I think Elixir has the potential of being like the JVM but for functional distributed programming. The JVM is fantastic and I do most of my work on it, but having an entire environment of consistent actors, fault tolerance, hot reloading, etc is a tempting proposition. Especially with the easy interop of languages & functional aspects. I don't think it will surpass the JVM, but I think it has a lot of potential in its own sphere of influence. Especially if the library support & technical contributions keep coming.

I think it would be quite possible to have the control systems completely offline, while installing a reputable alarm system that is connected to the internet. If those two things have no network connection, then you could monitor the premises, but even a remote hacking of that system would not enable changing of chemical levels.

I have projects that use ORMs and projects that do not use ORMs. I have specific reasons for both types, and in certain circumstances one or another is more appropriate.

ORMs are a dependency that are often constantly updated, prone to corner cases, and require a lot of library specific knowledge-- but they often make code more secure against small mistakes or tossing in a string interpolation, which is important when working with others, especially junior developers. They can be quite nice to work with in having type checked queries, building up queries from pieces using an API, but they also tend to be heavy and miss some features of your DB.

Raw SQL on the other hand, is very flexible, standard, easy to read, and anyone who knows SQL can jump in. You can do REPL for queries and copy in, and edits to SQL are easy. The only dependency you need is the standard database drivers, and updates don't typically break things. If you have a basic understanding and use it right, security is great as well.

Your post reminded me of my recent encounter with the phrase "damning with faint praise". It is interesting how applicable it is in authoritarian governments; you can't simply praise, you must give enthusiastic encomiums. That is particularly interesting in business, where it may be obvious to business leaders that something is wrong, but anything lackluster brings about government condemnation, which is part of the problem the business people can see. Startup founders are usually sharp, rebellious individuals trying to upend current business practices, so the condemnations damper the business spirit to some degree.

(https://en.wikipedia.org/wiki/Damning_with_faint_praise)

For some people, that _is_ their way of working, and it works very well for them. I think it is mainly the quick access with a regular, predictable arrangement completely driven by the keyboard. Low resource usage is a bonus. It is like having some of the benefits of the CLI but in graphical form.