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.
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
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.
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.
> 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.
There is something very fun about writing lisp for an Arduino nano, and trying to golf your intentions into ~300 characters :)