Counter argument. How do you know the user uploaded a corrupted image and it didn't get corrupted by your internet connection, server hardware, or a bug in your software stack?
You cannot accurately assign responsibility until you understand the problem.
This is just trolling. The JPEG is corrupt if the library that reads it says it is corrupt. You log it as a warning. If you upgrade the library or change your upstream reverse proxy, and starting getting 1000x the number of warnings, you can still recognize that and take action without personally inspecting each failed upload to be sure you haven't yet stumbled on the one edge case where the JPEG library is out of spec.
I don't think the port names is what they were referring to.
The actual names for each data transfer level are an absolute mess.
1.x has Low Speed and Full Speed
2.0 added High Speed
3.0 is SuperSpeed (yes no space this time)
3.1 renamed 3.0 to 3.1 Gen 1 and added SuperSpeedPlus
3.2 bumped the 3.1 version numbers again and renamed all the SuperSpeeds to SuperSpeed USB xxGbps
And finally they renamed them again removing the SuperSpeed and making them just USB xxGbps
USB-IF are the prime examples of "don't let engineers name things, they can't"
So everything I say in this comment is unlikely to have any real impact if you were to replace the cables and retest, but I'm saying it for educational purposes. The reason the specs are strict is not because it cannot be done on less but because the acceptable margins for error and risk are lower in non consumer settings.
That switch does have metal around the ports but I could not find any indication in a datasheet that it designed to accept shielded cables. I also don't know what other devices you are connecting to the switch. Proper usage of shielded twisted pair needs the shielding to make contact to ground on both sides of the cable. I was taught years ago that using a shielded cable with neither side grounded or just one side grounded had the potential to turn the shielding into an antenna and make interference worse than with an unshielded twisted pair cable.
The flat cable is concerning. Flat cables are not part of any twisted pair spec. There tends to be two kinds of flat ethernet cables. The first being completely flat with no twisted pairs at all and the second kind having each pair twisted around each other but then the four pairs are parallel in the falter sheathing. The second kind is better and from the pictures that cable might be the second kind. However 33 meters is very long for a flat cable. Ideally you shouldn't use them but if you have to keeping them very short like under 2 meters is ok.
The pages for the other two cables never even show the cables but what looks like 3d renderings. I personally do not like that and it makes me think less of the vendors. I doubt any of the three cables would pass a full qualification test for Cat7 but they are probably completely indistinguishable from qualified Cat5e (since you are only using 1g) unless you are using them next to high voltage power conduits or next to a high power broadcast antenna. This just comes down to "Cat7 consumer products are a marketing scam."
At least now instead of just theory we have one study of the results and a data point to use in the next attempt at a similar project. The idea is probably still solid and could be attempted again but with a more refined implementation.
Absolutely agreeing with you but replying to you instead of multiple others below with my views on this.
Cat6A can do 10Gbps at 100m. Cat7 and Cat8 can do higher speeds in short runs but those technologies are DEAD in DC tech now. 40G is legacy tech using four lanes of 10G, replaced by 100G which is four lanes of 25G. Copper patch cables are not used with these, everything is fiber or DAC.
If you use a Cat7 or Cat8 cable the higher MHz support listed on the spec will never be used. When using a real cable of these qualities all you are really getting is better protection from outside interference.
When buying premade patch cables only buy Cat6A. Anything you see online saying Cat7 or Cat8 has probably never been properly tested by the manufacturer.
When buying a spool of wire do your research on the manufacturer. There's plenty with false labels out there. I once saw a spool of 'Cat6e' which is not a real standard.
When paying others to run cables find out what brand and what warranty the installer is providing. If they only use Cat7 and cannot provide a good explanation on why they might not actually know as much as you should be expecting them to.
In the sovereign citizen cases they are talking about, the typical case is that the vehicle is not registered/doesn't have plates and the driver refuses to identify themselves. They only barely lower the window if at all. They usually go back and forth a few times until the police tell them they are under arrest for multiple reasons relating to driving without a license and failure to identify.
The glass breaking happens after multiple offices have arrived for backup as the person usually gets dragged from the car screaming. The videos are extremely entertaining to watch.
The combination of unregistered vehicle, failure to prove the driver has a license, and the drivers insisting they should be allowed to drive away is absolutely a combination where arrest is legal.
The author has obviously never tried Tauri on Linux. I've never seen one of their AppImages work correctly. Every project uses the upstream GitHub action to build binaries and it compiles dynamically linked binaries limited to the glibc from the Ubuntu 22 or 24 VM used. Xdg-open is often broken too from broken environment variables in the AppImages, so you can open a link in the default web browser. The entire build process needs reworked.
It is not surprising that a libc headed by the chief gnuissance would produce sn ecosystem where everything works better when apps are compiled from source for each distro.
AppImages are supposed to be able to handle all of that and I have used a number of them that do. In the case of Tauri though it seems nobody on the framework team knows Linux well enough to fix the build process to not constantly break as libraries update on the GitHub Ubuntu VMs or to make all the required dynamically linked libraries get included in the AppImage. And finally most of the downstream app developers have never written an app for Linux and chose the framework expecting it to solve the problems it clearly isn't.
Yeah, I switched to Linux and my single Tauri app was not cooperating.
They do have an effort to use Chromium Embedded Framework for rendering the webview, it's potentially much more stable in Linux. [1] It is nowhere near finished but you can run the cefsimple example, and it rendered me a window in Wayland.
CEF is also bundled in many distros, like Fedora 43, so if it can be linked with Linux distros version of CEF, then the binary stays smaller.
I've been a lifelong Linux user, and this makes me sad.
I don't know enough to comment about whether or not it's necessary, but any time I've tried to get anything working that wasn't updated recently, it was impossible.
Well impossible is a bit strong, the process ranges from:
- Find a forum post that links to some old .deb files and install them manually
- Install a newer version of a dependency and then recompile from source code, after spending an hour or two updating the program so it works with the new version of the dependency because the dependency changed its API for no reason (that one's not a Linux problem per se, but it wouldn't be necessary if the old one still worked!)
Better to download the Windows version and run it in WINE...
Sadly, every time that one guy posts his personal finance app on HN I try it and every time tauri gives me trouble to build, and when I fix whatever build errors it gives me it basically opens up a blank window and the app doesn't work (He now offers a Docker image which I can't help but feel is related to these difficulties).
I think the blank window bug was caused by a change in the libraries used by the webview on Ubuntu 22.04 used by suggested build action. Details and fixes were spread across bug reports in multiple downstream projects but afaik it was fixed in an Ubuntu update.
I really wanted to use tauri instead of electron, but the libwebkit it uses on linux is just too slow for modern CSS/html, from memory I managed to get single digit fps just scrolling the components page of daisy-ui. I am holding on for when they get a servo integration.
Recently I tried Electron app, it didn't work out of the box in Ubuntu 24.04 (AppImage). Turned out some issue with apparmor. It worked if extracted manually, though, but that's a bit of friction for ordinary users, also probably wouldn't work with updater.
In my experience building Kanmail neither Tauri or Wails have this figured out. I had to combine elements of both projects custom linuxdeploy GTK plugin and I’m still not 100% sure it works everywhere. https://github.com/Oxygem/Kanmail/blob/19c5bfe78fe1b22147c01...
Yeah.. It's pretty damn hard to get working at all, and the systems it does seem to work on is quite limited as well. And also the developers of Tauri largely have seemed to have given up on Linux (which to some degree I understand, it represents a tiny amount of users for 99% of the problems due to the massive diversity in the ecosystem of Linux DE)
I fight with GitHub Actions on this all the time, and damn near think about running dedicated instances just to build from.
En Croissant and Pawn Appetite use Tauri (chess interfaces), neither ever works, got so annoying I just setup docker to build them on fedora and copy the binary out via scratch stage, needed to install one library and now both work.
Tauri itself seems fine but the packaging in AppImage is exactly as you describe, or EFL just breaks.
Using `zig-cc (clang)` to set a particular `LibC` version is one of the best decisions i have made, and saved me from those meaningless libC mismatch errors!
Yup, came here to say this. After reading the article, it became abundantly clear that the author doesn’t support Linux and most of the article is just a summary of the common Tauri talking points that are out of date. To add data to this - Tauri is looking to allow embedding chromium as an option because the creator of Tauri acknowledged that it doesn’t work well on Linux. To the point where if Linux is a serious target, they don’t recommend Tauri: https://github.com/tauri-apps/wry/issues/1064#issuecomment-2...
The upstream projects aren’t in a place to support this yet so this feature didn’t make it into Tauri v2. I’ve been tracking this for a long time and hope that they will make it possible in v3.
Thanks for the link. That's great info to know but it's only part of the problem. If they think changing out the renderer will fix everything then they haven't learned anything.
Their build action creates seriously flawed AppImages for Linux for multiple reasons that have nothing to do with the renderer but with the AppImage creation process.
Good to know. Every time I gave Tauri a shot, issues with the state of WebKit on Linux was always my first hard wall. I never got to even trying to make a production executable. Sounds like it’ll be a long time before this ever becomes viable for fully cross platform use cases.
The OG Steam Controller didn't really fail though. Valve stopped production and sold the remaining stock because of a patent lawsuit over the rear paddles. With more time on market it probably would have grown and evolved.
You cannot accurately assign responsibility until you understand the problem.
reply