spsesk117

ulisp is an incredible achievement and has brought me a lot of joy.

There is something very fun about writing lisp for an Arduino nano, and trying to golf your intentions into ~300 characters :)

I'd be interested in hearing an expanded take on GPLs presence in this list.

The first and third elements are intuitive and confirm my own biases/believes, but the freedom/GPL entry confuses me, as I do see GPL fulfilling that purpose (arguably in a highly opinionated, perhaps sub-optimal way).

If anyone could share their perspective here I'd appreciate it.

Thanks to the author for the fascinating and detailed write up. It feels like a lot of the time this level of detail around the specifics of 'blessed' (not homebrew) console porting are only revealed years after the end of the consoles lifetime.

As an aside, reading about this kind of deeply interesting work always makes me envious when I think about the rote software I spend all day writing :)

I attempted to write a program once to solve for how annoying it can be to notate modular patches.

It's essentially a small DSL that can produce graphviz charts of patches. There have been other attempts to do this kind of thing, but they rely on the writer to describe their modules, which makes it quite tedious. I wanted to have a 'library' format that would allow people to specific module interfaces once, and then they could be imported.

I got a basic prototype working in Perl if anyone is interested, but never got around to really polishing it up and writing a bunch of 'libraries' for different modules.

https://git.spwbk.site/swatson/modmark

Interested if anyone knows of / has written something better.

At some point I heard the phrase: "Always be the dumbest guy in the room."

I've tried to live by this to various extents, and it's kind of a counter-intuitive phrase, but the more I've thought about it the more it's made sense.

For me the phrase encapsulates a few things:

- Surround yourself with people who are 'smarter' than you, you'll learn more

- Be humble. It's hard to learn anything when you're the 'expert' in everything.

- Give yourself and (by example) others permission/space to not know things

This article reminded me of that.

I would love to have been a fly on the wall at the Beeper offices over the past few weeks. I've had a hard time guessing their intent.

To some extent all of this Beeper Mini stuff seems to be almost an elaborate marketing stunt. I don't say that to diminish the impressive work of the team of anything like that, but it seems self-evident that Apple would hate this and I've been a bit surprised by the tone of the company throughout the past few weeks. The tone feels a bit like they've been surprised by Apple's response?

With all of that said, I'm kind of selfishly happy they seem to be returning their focus to Beeper Cloud. I've been a very happy user of it for a while now and I don't particularly care about the iMessage functionality.

I'm very impressed with what they've been able to achieve and overcome when taking on Apple here, and I'm really interested in where they'll go next.

I am a complete layman in the world of complex computer graphics programming and research, but I have an interest in it as someone who enjoys playing computer games.

I really enjoyed this succinct YouTube video on the topic, for those interested in a primer: https://youtu.be/HVv_IQKlafQ?si=y9gdS-1UkmdTX2Ik

Would you care to elaborate? I'm not an expert in this area so I'm probably missing something, but my thought has always been the 'portability' of storing everything in the backend as UTC is more flexible/less complex in the long run, dealing with conversation at the 'last mile' so to speak.

Happy to be corrected here but it's not intuitive to me that dealing with timezones as the 'base unit' makes anything easier.

I'm from South Africa, so I've always been captivated by the South African season/win at the 1995 Rugby World cup and the political context of it. Dramatized in the movie Invictus.

I don't know if it's the best sporting moment of all time, but it's certainly an interesting one.

Witch looks awesome, and I think has a killer feature I've been looking for for a while on linux (slightly off topic).

I use rofi on linux to surface a dialog that allows me to execute programs, surface an X window, or change to a different tmux session. Rofi natively supports the first two, the tmux pane/session switcher being a little 10 line extension I wrote in bash.

I love rofi and the ability to do this, but there is a 'white whale' in this workflow setup that I have not been able to crack: A rofi dialog that displays and surfaces browser tabs. I have fought with chromium dev mode/flags/options on several occasions trying to plumb together something like this, but cannot for the life of me figure it out; apparently chromium does not really want you to get a list of tabs from outside the browser.

Has anyone with a similar workflow found a solution for this? I'd be willing to switch browsers, or try anything really.

I've always felt that $BIG_BRAND_DISTRO+KDE got pretty close. It's still Linux, so not quite the same, but as far as look and feel, it's pretty close I think.

Disclaimer: I am friends with the founder of log-store.

I have been beta testing it for a while for small scale (~50 million non-nested json objects) log aggregation it's working beautifully for this case.

It's a no nonsense solution that is seemless to integrate and operate. On the ops side, it's painless to setup, maintain, and push logs to. On the user side, its extremely fast and straight forward. End users are not fumbling their way through a monster UI like Kibana, access to information they need is straight forward and uncluttered.

I can't speak to it's suitability in a 1TB logs/day situation, but for a small scale straight forward log agg. tool I can't recommend it enough.

Disclaimer: I am friends with the author of log-store and have been occasionally helping test the software.

I've been using log-store at work for some time. It has an awesome 'admin' UX. The sysadmin/ops overhead associated with getting something useful out of log aggregation and analysis is so much lower than tools like splunk and elasticsearch.

If you're interested in getting some kind of log analysis/aggregation spun up quickly and don't need all the complexity associated with things like ES and splunk, definitely give it a test drive.

I wouldn't call myself a security person, but I do have a fair amount of experience implementing things downstream of the security organization, and sometimes outside of that context.

I think a reasonable place to start is something like the NIST Cybersecurity standard. In my limited experience, the NIST Cybersecurity standard deals more with _risk_ than it does with discrete technical guidance, but from their fairly comprehensive risk framework you can start to frame the technical problems in your environment through this risk lens.

Additionally, I'll recommend something that's maybe wrong (security folks jump in as needed), but I typically try to work outwards in when securing an environment. In the case you've got a web app or something, reduce the attack surface of the system externally as much as possible (closing ports/IP filtering on management ports/etc) and then work your way inwards.

Put another way, try to focus on bang for you buck until you have a dedicated a team. An obscure XSS that requires a strong working knowledge of the system is _very bad_, but if you also have port 22/SSH open to the world with a 5 char password, I'd figure that one out first. That's obviously an extreme example, but I think you get the point.

Right there with you Urist. Nothing else out there hijacks my brain quite like DF...

I don't think I implied making a package wasn't simple...from my comment:

> With that said, it is a mature, standardized process, and is fairly painless in the self-hosted/non-upstreamed case

> the solution isn't "well, why don't they just use existing package management systems"

Fair enough, I think I was more trying to unwrap the idea of "shell script standardization", which to me feels like a package management system.

To your point about the challenges of packaging for multiple distros, there are force multiplying tools I've used in the past that make this easier, but in my experience it is always a big challenge.

My hope is that things like Nix or even something like brew can help to further consolidate the installation process for software going forward, so that everyone can have the best of all worlds :D

> I think what's missing is some standardization around what an installer is allowed to do

I don't mean to be facetious, genuinely curios, but to the authors point, isn't that the point of the package management system? It's a standardized and encapsulated way to provide software, with sane defaults, in an auditable way, that respects the users system.

I tend to agree with the author here, but I'm sympathetic to the maintainer: packaging for rpm/deb (in my experience) can sometimes be an enormous pain with many hoops to jump through, _especially_ if you're trying to get your package accepted upstream. With that said, it is a mature, standardized process, and is fairly painless in the self-hosted/non-upstreamed case.

Disclaimer: I know the developer of Ntfy and have worked with them in the past.

I love this tool because it sits in a very convenient place in the alerting and monitoring stack.

At work the kind of alerting pipelines and frameworks needed can by necessity end up being nontrivial and somewhat sophisticated. If you run some stuff at home or in the cloud or whatever, I have often wanted some kind of simple alerting but never want to deal with mocking out similar systems that I've built at work.

Ntfy sits perfectly in this space, and I've used to to frame out my own kind of micro-alerting frameworks for a bunch of stuff that I run. It's incredibly easy to encapsulate in something like a bash TRAP or even || conditionals on random cronjobs, and just makes getting some kind of alerting so trivial. As such, it's spiraled out into a lot of different stuff that I run.

I feel like you just described Perl, and I use Perl almost every day for this kind of thing, but people seem to hate it these days.

The syntax can be weird, but I still think it really shines in cases like these.

What got you excited about this field in the first place? Try and get back in touch with that maybe.

Try exploring another side of the field, like systems programming, or a language like Haskell. Maybe play around with Python ML libraries.

I realize this doesn't really answer your question, but for me personally, passion for messing around with computers has been a constant in my life.

Other things come and go, but there is always something interesting to be done with computers. If one area starts feeling boring or uninteresting, there is a staggering fractcal of interesting problem areas in computing, that seem to spiral out infinitely.

If Web/JS/React/etc feels boring and uninteresting, maybe look at some other space in that fractal.

This is excellent advice. I just wanted to add, don't underestimate the haircut. I've used this strategy several times to make clear dividing lines in between various periods of my life. For me creates a strangely tangible distinction between what are ultimately arbitrary points from the outside looking in.

I use regex101.com a lot for writing complex regex.

It provides a very quick feedback loop for thinking about how I want to struct regex and be performant/safe in my implementation.

I'm interested in whether the technologists employed by this company will be able to pull it off. I'm by no means an expert, but my understanding is that in order to support a large scale social network, with typical social network features, the implementer needs to have some pretty robust solutions for a large breadth of different problems/design considerations.

On the one hand, a lot of the technology used (in what I imagine a typical high level social network design would be) is readily available and well understood by actors in the job market (I think?). On the other, assuming there is a wide audience who would be interested in immediately using this product, I wonder if they'll be able to pull it off without being plagued by D(D)oS attacks, targeted hacks, etc etc.

Note: To be clear I'm just riffing on the technical challenges of this undertaking (making a new social network) and not trying to get into a political/ideological argument.

I definitely agree with the line of thinking posited, what I'm less clear on is what the discrete implementation of these ideas looks like.

I worked at a company once with huge monolith system, mainly revolving around a relational database. We tried for years to break out of this, and if my understanding is correct this organization is still on this monolith today. There were a number of challenges, and we tried a number of different solutions (NoSQL models/object stores/etc), but it felt like there were base level assumptions about the availability of data in the core application that felt impossible to address without a full scale rewrite and reevaluation of all previous assumptions.

Perhaps I've answered my own question here -- it just needed to be completely redesigned from the ground up. Short of doing that however, would anyone care to provide high level insight on how they'd break down this problem, and what technology they might use to address it?

Thanks for the link, I'll definitely check it out! What actually piqued my interest was the surface impression of something like a Lispier Perl/Python.

Oh awesome, thanks for sharing, I have already been looking at some community examples on there!

Wow! Some really cool projects, thanks for sharing, I'll definitely check out Freja later this evening!

Thanks so much for the info and commentary!

This looks really interesting, going to check this out later today. Anyone using Janet for anything that would care to comment on their experience?

Wow. Thanks for all of this info and for your very interesting perspective. I have a passing familiarity from HN and elsewhere with some of these new shells, but am not well informed enough to really comment on their usefulness/etc. With that said, you've given an excellent primer in your comment -- thanks very much!

A few things you said stuck out to me:

> For me, the great thing about a shell language is that it's a programming language I get to _live_ in.

> The idea with these new shells is to try to find a way to enhance the programming capabilities of shells without making them any less convenient for navigating the filesystem and performing simple tasks with external programs.

Generally, I agree, and I actually use `eshell` in Emacs for this kind of thing a lot. Being in a pseudo-shell LISP layer allows me to get arbitrarily manipulate text I get back from the command line with elisp and allows for some really flexible workflows. With that said, eshell does of course have many trade offs and limitations, which I won't get into here.

I think where these things always fall apart for me though is in the Elvish shell example you provided. To me, that is not functionally better than using Bash and jq, it's just different. Maybe it's better, I'm not sure, but my first impression is that it's neither more concise or more readable, it's just different syntax.

I think there is a credible argument to be made for "batteries included" type shells, with something like native json parsing, but at what point does it then tip into being like Powershell or Python, where once again you've gotten away from the native/accessible experience because you need to support `n` kinds of structured data inputs/outputs on `n` platforms?

As I was reading your comment, the thought that occurred to me was: Why not just make a python library that can be loaded into the REPL that abstracts over some of the more cumbersome parts of interacting with the OS/filesystem in a shell like way? That seems to be the best of both worlds, and from what I gather that seems like what Rush and Xonsh are doing? I need to look into them further.

> Developers and sysadmins want to be able to pull in structured data from whatever source and query it and manipulate it right there inside their shells. But each format gets its own utilities for that kind of querying and manipulation, and they don't necessarily know how to talk to each other.

I agree re: structured data manipulation, but I think the solution that has naturally emerged exists for a reason. I can use pipes, and programs like jq to push and pull data into and out of whatever format I need, and each layer of that ecosystem can be maintained in parallel, adapting to changes in the overall landscape. In a sentence, it's the core of the Unix philosophy. One thing and one thing well and all that.

I dunno. I've thought a lot about it while typing this comment out. I think it sounds like I'm disagreeing with you, but I'm not. I don't even really think we're debating. I think these new ideas for shells are good things, and I will definitely investigate them more and see if they make my life easier. I just can't seem to shake this feeling that we can't have our cake and eat it too. Maybe I'm looking at it the wrong way though.

Maybe in 20 years time shells like Oil and Elvish will be the norm, and we'll be complaining about how they don't handle quantum data structures well without lots of pipes and fd's :D

Either way, this has been a very interesting digression. Thanks again for your thoughtful comment and insight.