151–160 of 171 posts
People will do anything to avoid learning the basics. Nothing new.
Do you have a link for me? I'd like to learn them, but find it really hard to find them. For example, I had never heard about etc/services until 2 minutes ago
Unix and Linux System Administration Handbook by Evi Nemeth et al.
I'm pretty sure Arch wiki is worth reading, too.
It's like someone should make a file... maybe in /etc ... and put short names for services in it... maybe it could be called /etc/services...
This is exact problem I see with all of those vibe coded software: In few years everything will be super fragmented, everyone will be using their own set of tools, or vibe coding them, themselves. Communication between teams or even between team members will become very hard because of those differences. 'What do you mean production is down? On my vibe coded dashboard everything is green!'
Earlier quoted context omitted.
> I put them in there That seems to run orthogonal to this. The primary benefit I see here is not having to care at all what ports apps are actually starting on. Just run them, and access them by name. Same as a regular website on the internet where one doesn't care about the IP. > How much care would they have possibly put into reviewing Just enough to ensure that it works for them, which is what really matters. Oth…
> Just enough to ensure that it works for them, which is what really matters. If that's what really mattered they wouldn't have posted an article they didn't write trying to get traction on a product they didn't create from a userbase that doesn't need it.
Doesn't matter if they didn't actually write the code, but they put effort into refining an idea for a problem into a solution that fit their needs, and in sharing they've given those who never thought of it a base they can work from if they want or just go make something similar from scratch.
Earlier quoted context omitted.
I mean that to connect to a service you wouldn't need to know the port, the IPv6 address would be enough. This is why I consider ports a layer violation of sorts. You never talk to a machine with TCP/UDP, you talk to a service on a machine. And so as it is the full address to the service isn't just the layer 3 address. As I mentioned this would be especially interesting when hosting multiple services, same or differe…
Yeah, but I mean you just have to have something on the transport layer, you can't just encapsulate application layer into network skipping network, that's not how the network stack works.
As I said you could implement it by having TCP/UDP as is, just with a fixed port number. This wouldn't be unlike the myriad of other conventions that litter IPv6, such as using /64 for a host or ULA's having a certain prefix.
Earlier quoted context omitted.
Why?
What's up with the hate? It seemed like an interesting project to me, maybe not something I see myself using, but not something deserving hate.
Earlier quoted context omitted.
this is a nice idea, but idk why, in macos if i do `nc -l 127.0.0.1 gopher` and then try to open url " http://127.0.0.1:gopher/ " - safari does not open it, no requests visible in the `nc` output. also `curl -v http://127.0.0.1:gopher/ ` gives error message * URL rejected: Port number was not a decimal number between 0 and 65535 * Closing connection curl: (3) URL rejected: Port number was not a decimal number between…
> http://...:gopher is it http or gopher? :)
Earlier quoted context omitted.
this is a nice idea, but idk why, in macos if i do `nc -l 127.0.0.1 gopher` and then try to open url " http://127.0.0.1:gopher/ " - safari does not open it, no requests visible in the `nc` output. also `curl -v http://127.0.0.1:gopher/ ` gives error message * URL rejected: Port number was not a decimal number between 0 and 65535 * Closing connection curl: (3) URL rejected: Port number was not a decimal number between…
Sounds like you need an AI agent that can determine whether http and gopher are the same protocol
zdw: It's like someone should make a file... maybe in /etc ... and put short names for services in it... maybe it could be called /etc/services...
tolciho: And then they might code up some sort of service lookup tool thingy to use on the train wreck that is the modern web.
$ getent services gopher
gopher 70/tcpEarlier quoted context omitted.
And then they might code up some sort of service lookup tool thingy to use on the train wreck that is the modern web. $ getent services gopher gopher 70/tcp
this is a nice idea, but idk why, in macos if i do `nc -l 127.0.0.1 gopher` and then try to open url " http://127.0.0.1:gopher/ " - safari does not open it, no requests visible in the `nc` output. also `curl -v http://127.0.0.1:gopher/ ` gives error message * URL rejected: Port number was not a decimal number between 0 and 65535 * Closing connection curl: (3) URL rejected: Port number was not a decimal number between…
“http://127.0.0.1:70/“ is unambiguous since 70 is not a valid host.
Earlier quoted context omitted.
i chose gopher port just as an example. try with any other service name mapped to a port number from /etc/services and the result will be the same. the OP's goal was to use many http/https services, so we are talking about many http(s) services. i just wanted to make the point that even if you have service names in /etc/services, it is not possible to use that names easily to host/access http(s) services.
The names are the kind of servers that listen on those ports (by default) like ssh, telnet, http, and smtp. They are not subdomains or for URI parsing.
the OP made a tool which helps them to avoid using port numbers. people commented in a way that looked like laughing at him, like he reinvented the wheel, and talking about /etc/services. well ok, i decided to try using /etc/services for the purpose of using names instead of port numbers.
would it be possible to add "myapp 60001/tcp" to /etc/services and then work with "http://localhost:myapp"? NO! browsers do not translate these names into port numbers. netcat does. curl does not.
so probably the OP's solution is not that questionable and really solved their need? and "good old friend /etc/services" is not useful for this? i dont know what it is useful for as running services on non-standard ports actually helps with hiding from security/vuln scanners and is practiced widely.
Earlier quoted context omitted.
i know, but the OP's goal was to host/access http(s) services with names and avoid port numbers, and gopher service name was chosen by me as an example. my point was that /etc/services cannot be used for the OP's need. if you host an http(s) service on port 11111 you can reach it with url http://127.1:11111 , but url http://127.1:vce/ would not work in most software. $ grep 11111 /etc/services vce 11111/udp # Viral C…
But if you want to contact vce, why use „http“? It‘s not going to work
how about "ssh://git@ssh.github.com:https/golang/go.git" instead of "ssh://git@ssh.github.com:443/golang/go.git"? does not work, hmm.