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 :)

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.

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.