Hacker News Reader

Comment by charcircuit | Hacker News Reader

>your graphics driver isn't loading/working

This is a bigger problem that should be fixed ASAP. OS vendors should never critically break graphics on a OS like this.

>you can't log into the GUI due to a bug in the login screen;

Again, the QA department or automated tests of your OS vendor should not let this get released. If such a bug happened there should be a fix rolled out immediately.

>you are working on a server that is headless

Why do you need to run the browser on the server? I can't think of a case where you would want to use a text browser there instead of a regular browser on your actual machine.

>so I had to boot into a system via a USB stick, chroot into the system, then install the uninstalled desktop package.

It's disappointing that you had to manually fix it compared to it just downloading a fix automatically like what would happen on Windows, Mac, iOS, Android, etc.

View on HN

> This is a bigger problem that should be fixed ASAP. OS vendors should never critically break graphics on a OS like this.

> Again, the QA department or automated tests of your OS vendor should not let this get released. If such a bug happened there should be a fix rolled out immediately.

On a Linux system, if you go messing around with your configuration enough, you will eventually break something. You are effectively your own QA department in this case. As a kid I did this often, it’s part of the learning process.

> Why do you need to run the browser on the server? I can't think of a case where you would want to use a text browser there instead of a regular browser on your actual machine.

You just need to look something up quickly to fix something and you are in front of the server. Or you need to download a configuration file from GitHub and the URL is really long, but you can get there in a few seconds from a web browser. There are other means to get the files to the server but they require more effort, and you are lazy (as is your right).

>if you go messing around with your configuration enough, you will eventually break something

If changing a setting breaks your OS that badly, that is a high priority bug that your OS vendor should fix immediately.

>You are effectively your own QA department in this case.

Linux users should hold their OS vendors to a higher standard than accepting that a user should become QA.

>You just need to look something up quickly to fix something and you are in front of the server.

Typically if you are in front of a server you have a client capable of running a web browser.

>Or you need to download a configuration file from GitHub and the URL is really long

Copy paste is fast even with a long URL.

> Linux users should hold their OS vendors to a higher standard than accepting that a user should become QA.

Yeah I’m going to demand my money back next time I break X.

Just because something is free. It doesn't mean you can call out unprofessional behavior. Since macos is free should all macos users ask for a refund when they encounter something they don't like?

MacOS is included with the price of Apple hardware.

I’m glad the Linux community doesn’t engage in too much professional behavior. It would be really annoying if Linux was as locked down as a proprietary OS is, and I suspect contributors would find the whole thing less fun, so they’d share less code as a result.

That would be offset by a larger number of people contributing as part of their job. Take a look at the Linux kernel itself as an example of this.

Blink twice if you are trapped in Windows and need help.

Is it an OS vendor “bug” if I delete system32.dll (despite all the warnings) or remove my hard drive and flush it down the toilet?

Maybe we have a different idea of what constitutes a “bug.” In my view, preventing users from running their preferred software or configuring their machine however the hell they want to is the “bug.” Forcing AI into every nook and cranny is a “bug.” So your OS vendor can shove it. I am my own OS vendor.

Yes, your OS shouldn't allow you to break the OS. There is no user benefit in letting the user due such a thing. Only user harm.

Well mine allows it, and if it is ever “locked down” to the point where I can’t do what I want to with it then I will patch and recompile to regain whatever I lost. Such is the beauty of open source. I can twist it, shape it, or even break it if I want to.

There is no benefit in allowing critical components of the OS to be deleted. Why would you add such functionality back when the only practical ability you gain is the ability you break your system and have to waste time fixing it. It's bad design.

> Why do you need to run the browser on the server? I can't think of a case where you would want to use a text browser there instead of a regular browser on your actual machine.

I've had to do that on my VPS a few times when I was debugging my Apache setup and needed to look at a web page that was only visible on the VPS, i.e., not available to the outside world.

Honestly I really agree with this use case and I even created a point asking for some browser like this but one which is more capable than even browsh perhaps, I am not sure if text is just the right choice, we need something between text and complete vnc install or debugging instance

You can take a look at pinggy.io / tunnl.gg and so many other options where you can just use the standard ssh command to port forward a port for some time and so you can debug it

I recommend you to take a look at this as well https://github.com/anderspitman/awesome-tunneling?tab=readme...

Third party driver vendors can crap out a graphical login pretty trivially.

If your driver messes up DWM.exe it can blow your whole compositing service and draw every window in software mode which is, without exaggerating, 10000x slower than Direct Draw/GDI back in the day.

Ever played an old Direct Draw game on Windows 8 and up? It will crawl. The game can only be played with WineD3D, which is basically a Wine build for Windows and it has ddraw.dll hoooked to its own DirectX or OpenGL libraries. This is the only way to get these games running fast again.

On software rendering for the whole desktop, the same. A text mode browser (or Dillo, or Links2) can be runable at useable speeds before downloading an updated driver or patch.

By the moment you try Chromium or Firefox with no acceleration (even under current machines), when you have to run both DWM.exe, the rendering process and desktop done with software rendering in CPU, it will slow down like hell because on top of that it will run some JS crap in the browser for granted on vendor driver pages.

Maybe a current i7 can withstand it, but not for long as browsers love to spawn threads and eat RAM like crazy. Add a 4K display and say goodbye to performance.

> Why do you need to run the browser on the server?

I often need to authenticate against one of my Fediverse servers (as part of `toot login` for getting access tokens) and it's easier to open Lynx (which toot will do directly) for that on the server than copy+paste to and from a "real" browser.

Most terminals let you just click a link from the terminal to open it in your browser. The convience of an actual browser trumps a text only browser so I think it would end up being the experience most users would prefer.

> Most terminals let you just click a link from the terminal to open it in your browser.

Which involves moving my hands off the keyboard and to the mouse/trackball/trackpad. With the text browser option, I don't have to move my hands anywhere.

One of my main uses for text browsers is scraping. They are typically lightweight and efficient, easy to script against, and I won't end up with premature optimisations where I immediately parse out small pieces of information and discard the rest of the page. Instead I store the dumps and can return to them at a later time when the problem domain changes or I have learned more about it.

Reply on news.ycombinator.com