Highly recommend fly.io as well; I started an elixir app for a client and decided to use fly.io and very impressed with how easy it is with the feature set so far.
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).
I did hear this week that Autodesk Construction Cloud is currently banned from military projects (was in use and is not currently permitted) because of something to do with security policies; but I didn't find out what exactly was in violation, does anyone happen to know what the issue is/was?
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.
I second this. When I saw that they were moving to subscription I was suspicious, but with the fall-back license and discounts for subsequent years' updates, I'm very happy with it. I have the All Products Pack and love it.
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.
Maybe this is a dumb question, but even if equipment isn't producing cutting edge chips, why can't they just produce slightly less performant chips and sell those for other purposes or at a discount? The article seems to imply that anything less than the best is useless.
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 dealt with that accidentally by finding "Boots of Blinding Speed" off of Pemenie in the western swamps; then later finding the Cuirass of the Savior's hide in Tel Fyr. It increases run speed a ton, and it works with levitate, so if you have the levitate spell you can speed around the map.
> 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.
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.
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.
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.
https://www.wired.com/1997/11/chaos-in-britannia-ultima-face...