FWIW it looks like this addresses the pipe error behavior: https://github.com/nushell/nushell/pull/16449
HN user
joemccall86
I can answer for me coming from the same boat... exactly zero risk to try, given how easy it would be to rebase back onto silverblue. I didn't have to worry about the codecs Fedora couldn't legally ship so I could remove an overlay, plus I figured bootc was the future and I wanted to see it working.
I'm a little surprised that an LTS product is based on CentOS 10 stream. Doesn't that have the shortest support?
We followed https://whichjdk.com/ and chose Amazon Corretto
I used Obsidian for a while, but for some reason https://silverbullet.md ended up resonating more with me.
I've used https://github.com/vi/websocat in the past and had very good luck with it.
Not sure if it's the hug of death, but this search generates a 500: https://search.brave.com/search?q=Spring+Boot
It sounds like you and I are thinking along the same line: https://github.com/joemccall86/cap5600-project2.
I am also taking AI this semester and was considering expanding upon something like this for my masters' capstone project. The application of machine learning to this type of situation is going to be very interesting to say the least.
Just wanted to say good luck!
This will probably get buried, but this story had me shudder at the possibility of being locked out of my 1password vault in a similar scenario. In case anyone is in the same boat:
* My airplane-mode test passed both on my mobile device and browser (1password X).
* The team is aware of the situation with LP and wrote a very thoughtful response: https://discussions.agilebits.com/discussion/comment/544136/...
* From the response above, 1password is SOC2 certified, so availability is taken very seriously.
Works with my media keys too. Nice work!
If you are on a unix system with vim installed, fire up "vimtutor" and learn basic vim usage. At worst you become at least more productive on the de-facto editor installed on most unix systems. Personally I find myself incredibly more productive using vim over most other text editors.
One thing I'm keeping my eye on is the fargate virtual kubelet [1]. It seems to offer a way to use the familiar kubernetes tooling with a managed "clusterless" offering like fargate.
Looks like a neat concept. Would anyone here with experience managing this in production care to comment? Seems like it could be interesting if you need to reproduce the exact same software/OS on several machines as deliverables.
Interestingly, the logo is a direct copy of UCF's academic logo: https://www.ucf.edu/brand/brand-assets/logo-identity-system/. I wonder if there is a connection.
Absolutely! There's a big 4.0 release happening soon as well that includes micronaut integration. Furthermore, there are profiles you can start with today that let you create a react, angular, or vue SPA app powered by the grails back-end. Add the fact that it's a spring boot app as well and you get an incredible library of resources available to you. We've been running our app in production with relatively few developers.
This would be immensely beneficial, and long overdue in my opinion.
Is the conventional wisdom to still avoid self-hosting? I'd like to adopt k8s but managed hosting isn't feasible in our aws region or on-premise.
I'm curious if Crystal was considered given its speed and similarity to Ruby.
Interesting article. Our stack isn't using mongo, but reading these posts give me good ideas for how others manage their software lifecycle. I like their use of a pre-production environment as a step between QA/UAT and production. This allows for a clean trial run of anything new deployed to production, as well as greatly removing any deployment-day surprises.
Google Meet would basically not work for me until I enabled third-party cookies. Nobody could hear my audio.
I recalled https://en.wikipedia.org/wiki/Optimus_Maximus_keyboard from years ago. It looks like the successor uses an LCD screen: http://www.artlebedev.com/optimus/popularis/.
They are also working on graalvm compatibility, as of late July.
The more I think about this the more I'm actually on board with it. Users can't assume that a site is safe anymore because of a green padlock because HTTPS is so easy/cheap to implement, and this is a step toward re-training users to use a different means to confirm they are entering information into a correct page. There's too much risk for the green padlock to be used as a false sense of security.
Combine this with marking HTTP sites as explicitly insecure and I fail to see any downsides with this becoming the new norm (assuming other browsers follow suit).
I had to unblock google-developers.appspot.com from loading.
While there may be some important technological differences here, from an end-user perspective they already achieved this 5 years ago (https://blog.chromium.org/2013/02/chrome-app-launcher-develo...), removed it 3 years ago (https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...), and now they're adding it back in.
I like that we're moving forward, but on the desktop this just feels like, "Hey, look what you can do again!"
To better support mouse gestures, browserSettings.contextMenuShowEvent() has been added in this version. This new API can be set to “mouseup” or “mousedown” by extensions to determine when context menus should be shown.
Looking forward to using FireGestures in Linux again.
We've stuck with Grails for a few years now and I still prefer it over vanilla Spring Boot. Things like JSON views and GORM are still really nice to have.
I like the ambition. I've had a tinfoil-hat theory for a while that phone hardware is only built to last roughly 1.5 - 2 years gnerally before they physically begin to degrade. I've flashed new roms to a Galaxy S3 but it tended to reboot (i.e. hard crash) a lot still.
I'm a huge fan of Grails, but this definitely interests me. Spring Boot has come a long way. Groovy is still a great language (as far as being approchable from Java) but Kotlin looks like a lot of fun.
Interesting. Reminds me of rest shell from a few years back. https://github.com/spring-projects/rest-shell