Same thing that happened to Alaska airlines twice, supposedly fixed by a software update?
1,617 karma · joined December 7, 2015
We found that even with a web GUI, containers are just too complicated for the typical user "that knows nothing about containers".
Even with a GUI, no matter how nice it is, you need to learn about env vars, port mappings, cni networks, bridging, volume mounts, images, tags, host isolation, etc etc..
Our solution is to wrap apps into pre-packaged recipes. Pretty big trade-off of course, but it makes the installation and management completely fool-proof afterwards.
You can see some screen shots in the documentation here:
https://sentinelc.com/docs/user-guides/administration/manage...
Fuse does not support windows. If it did the extension could probably be easy to port..
Your best bet is probably running the browser under some wsl layer.
In many cases, you have a perfectly functional web app and the only feature you would gain from publishing a native mobile app would be push notifications. Apple used to gate this feature behind its app store/developer program. Now you have an alternative, and I think it was long overdue.
Apps run in a sandbox and have no access to user files except through "portals", which are secure file pickers essentially.
In practice you often get weird timeout issues and unintelligible errors in kernel logs, hard resets, drives disconnecting or worst, data corruption. It's also always difficult to tell if it is a failing drive, or if it's a controller bug, or power supply issue.
Too bad though that general purpose SBC's kind of suck for NAS/Storage though. Both the rpi4 and orange pi zero mentioned in the project lack any kind of SATA port and relies on usb to sata.
The best project I saw was the Helios4/Helios64 (https://kobol.io/), but sadly, they folded in 2021. Is there anything even remotely similar around?
Right now I am still using intel-based mini-pc's for diy NAS storage as they simply work better.
https://lore.kernel.org/stable/CAFsF8vL4CGFzWMb38_XviiEgxoKX...
A patch was backported to the 6.0 branch from the main branch, but they forgot a line of code, leading to a buggy behavior.
Good old bait and switch.
Besides issuing a prompt refund and hopefully banning the fraudulent host, what exactly is Airbnb supposed to do in such situation?
They operate a platform, not an hotel chain. They have nowhere to actually host you and are in no contractual agreement with the guest to actually get you a place to stay whatsoever. Buyer beware so they say?
That would need help from userland, which is not involved in the early boot process.
You could I guess change kernel init parameters and save that in your boot loader, but that is very hackish.
I have no idea why the hardware/software industry all focused on the linux kernel as the common base for so many hardware support. The amount of chips supported in the linux kernel is mind boggling.
I worked with FreeBSD in my early career. How do I miss the `make world`. So easy, all-in-one, clean and elegant system.
I had to migrate a couple of projects from awful, big ridden, wysiwyg editors to markdown and it's a huge challenge. Many people expect everything to work just as Ms Office/word does. Anything behaving in any way different than their benchmark is wrong..
Now, going from such a mindset to Markdown is a huge endeavour. You need to re-educate your user. Many will never appreciate the raw, code-like nature of markdown and will dread it the entire time they have to endure it.
So even though podman offers a compatible cli interface, if was no help to get compose to work.
podman-compose is a re-implementation of the docker-compose spec in a podman compatible way. Like any re-implementation, compatibility issues are possible.
The main podman project instead chose to tackle such incompatibility by implementing an optional daemon mode offering a compatible to docker REST api.
If you start de podman service on a recent version, you can use docker-compose as-is. It will happily send commands to the podman daemon and from my few initial tests, everything works perfectly so far.
At some point after an update, launching that app would take multiple seconds. How could the most basic gtk app be so slow to launch.
Investigating further, I found the update had transformed the normal gcalc package into a snap, probably just to prove how great snaps could be for desktop apps?
What a bad way to introduce your latest tech canonical. From then on, my opinion of snaps was very negative and I still do everything possible to avoid them. Even if they are technically great or more secure, canonical messed up their introduction and are now stuck pushing a dead horse.
Linux 6.0 could have been versioned as 5.20 but Linus chose 6.0 out of thin air. Nothing more nothing less.
Why would any tenant supplied data affect anything whatsoever?
As a tenant, unless you are clashing with another resource under your own name, I don't see the point of failing.
aws S3 would be an exception, where they make that limitation on globally unique bucket name very clear.
It's a maintenance nightmare. Poor, rushed together server components. Noone still around the company that still knows how it was built. No automated tests whatsoever, so any code changes or recompile with newer libs would require important QA efforts..
I'm not saying this justify anything. It's still very bad business practice and consumers are right to be mad. Kinda was predictable though, and game publishers should have a clear EOL policy when selling a game.
Usb ethernet adapters will send these pause frames, waiting for the computer to reconnect.. but they end up flooding dumb switches..
One or one calls should be using direct peer to peer connection thanks to webrtc.
Group calls will be routed by the server, so latency will be an issue depending on the server location.
It's committing the time and resources to get it in a good enough shape to at the very least be submitted upstream.
Embedded device drivers are often developed by cutting a lot of corners, copy-pasting huge amount of code, using magic register addresses that are undocumented and targetting old kernel versions.
Even if they make the code available, there is not much the kernel maintainers can do.
By the time the device hits the market, the driver developers have moved on to the next project in the pipeline. There is never the time to clean up, rebase on top of master, submit upstream properly, and address code review (of you are lucky to get a maintainer to even look at your code).
The DHCP standard was such a waste of time. Ignore it completely, no client support whatsoever.
Intercepting all plain HTTP traffic (just drop https) and responding with a 30x redirect to your captive portal web page seems to be the ad-hoc "standard". Your captive portal domain can be served under secured HTTPS just fine.
I fully agree with the sandboxed browsers pain and absolute impossibility to get a nice consistent UX across platforms.
Either way, a proper api doc/spec should make either approach a non-issue.
Personnally, I've switched to graphql where it makes sense. Application level error codes and handled on the graphql layer, not on the HTTP layer, so you could say I've adopted that approach!
The main idea of the article is exactly that he does not agree that http error codes be used for application level errors (as REST principles recommend).
I think at this point that ship has sailed. Most HTTP based API will use http error codes in various ways. I would be surprised to not receive a 404 when requesting a resource ID that does not exist for example when consuming a new API.
If you are in the room with the bot, you can issue commands.
They could have forgotten that you can also just add the bot to another room. Major face palm, but plausible.
With most everything fully encrypted, what's left for the rules to detect? If I remember correctly, one of the first performance optimization recommended by snort/suricata is to detect and skip encrypted traffic, to not waste cpu cycles on random bits.
If a malware wants to exfiltrate data or receive commands from a remote command and control, won't they simply masquerade their traffic as regular outgoing https requests and bypass the IDS easily?
Found a relevant article and discussion from 2016 here, so this problem is not new!