and take a good chunk of the gaming GPU market away from both Nvidia and AMD in 2019/2020
LOL. No.
The fledgeling hardware raytracing movement is cool to watch, but it's nowhere near replacement of rasterization. Even now it exists as a hybrid solution with numerous enough problems that adoption is nil.
Ultimately, it's game developers that will drive hardware raytracing. Awesome hardware without the game industry targeting your hardware leads to dead ends. How *is* your 3dfx gpu doing, anyway?
The IDE is cluttered, gets in the way and is painful to use. It is tedious
That's like, your opinion, man. And a minority opinion, at that.
I have to hardcode options, I can't use discovery tools to see what exists or where it is. As an autoconf/cmake replacement, it sucks.
Good god. You still use autoconf?
It's slow. Given the choice of VS or Emacs, I would use Emacs every time. Much less overhead, much more real estate.
Yes, and you'll never get a real job as a programmer. I love Emacs too. I use it for all of my scripting, and even small and simple linux C projects. Emacs isn't even an IDE when compared to the IDE functionality of VS. It's a really bitchin extensible text editor with some language punctuation and highlighting features. I'm beginning to wonder if you're even serious, here.
And that's central to an IDE, your real estate. It's mostly wasted in VS, no matter what you do.
Yawn. Your real estate is what is central to your IDE? I'm starting to piece something together here. What you need is a text editor. I'm wondering if you're really qualified to be forming opinions about what makes a good IDE when you're quite clearly an amateur.
Auto builds slow the computer down and are a bad design choice.
Again, are you serious? I don't know whether to attack the literal falsity of that, or the obvious solution to it.
Probably the best IDE I have ever seen for any language on Windows was Borland Turbo Pascal 3's. The Inmos folding editor was superb, Ada's GPS and Eiffel's GUI are decent. Vi and Notepad++ are brilliant (tools should never get in the way). Really, for programming help, Norton Guides were the best I've ever seen.
TP3 and BCB were both good products. Very similar to VS, but in a lot of ways better. But still, everything that you love about them, you hate about VS. Weird.
As for the rest of that horseshit, again... with the text editors. I'm sorry VS has too much functionality for you. I'm sorry you work on simple software projects, and are confused a lot of tools in your face. That's fine. Stick to your text editors, and the professionals will continue to use professional tools.
Next up, jd tells us about using Gimp for professional post processing.
Their debugger is dreadful. If that's the best you've used, I pity you. I don't use it, even if using VS.
Again, that's like, your opinion, man. And you're again a minority. But yes, using GDB is a fucking thrill [rolls eyes]
Indeed, I think you'll find Notepad++ beats VS in popularity.
Mmmh, no. As a text editor? Sure. Probably. VS is a little heavy for simply editing files. It is, after all, a fucking IDE- something that notepad++ *is not*.
More people might own VS with Windows but that's because you can't separate it from the compiler and most competing compilers oblige you to install VS even if you never use it. That's not popularity, that's antitrust.
Poppycock. You can develop for windows without VS. Furthermore, you can separate VS from the compiler as well. Hell, you can use GCC if you want. It's just a fucking IDE. It also, unsurprisingly, ships with compilation and linking tools, derp.
I'd love to start picking apart all the ways your selected software sucks, but not a single fucking one of them were an IDE, so I'm kind of at a loss here. Since they are pretty good text editors, I can't really shit on them too badly. What I can say, is you didn't have a single good point, your opinion is not only a minority one, but also ridiculously bone headed. And finally, you need to look up the definition of antitrust.
Na. They have pretty great development tools.
Now if you want to get into the specific performance and idiosyncrasies of their compiler, I'm on board.
Their IDE however is world-class, and earns its spot as the most popular IDE in use. Their debugger is also the nicest debugger I have ever used.
Your arguments are pretty lame, really. You list a bunch of niches that Microsoft apparently doesn't care about or attempt to compete in, and say that's why they rate poorly.
You suck because you've never gotten a medal in the special olympics.
Yes, I am in fact the idiot who has been written about in 3 books, invited to speak at a security convention regarding embedded linux kernel attacks, runs 14 DNS servers, and a network serving approximately 10,000 residential and business customers. The idiot who was also categorically correct, as evidenced by your own infallibility metric- whether or not Poettering conceded he was a moron and fixed the problem. You know what now resolves DNS hostnames with underscores? systemd-resolved.
Good luck learning computers, indeed. Enjoy spreading your ignorance across the internet on the backs of people like me, you dim-witted ingrate.
Get out of your basement. Get some sun. And maybe an education, or at the very least some lessons in humility.
If your grasp of other technical systems is a shit ass poor as your grasp of reading RFCs and DNS, then I doubt you get anything done "IRL" other than keeping your mom's computer running.
Yes, it was a joke. I'm however not even remotely surprised that you were too thick to get it.
Sure did! It was an attempt at humor by pointing out a paradox. I'm actually amazed you were able to find enough time out of being wrong about almost everything you say to notice! Congrats, ZK. You're almost not useless
Not that I see eye to eye with you in any way, shape or form, but after seeing his posts on the iproute2 discussion, he isn't qualified to offer an opinion on anything Linux related.
This can all be boiled down to,
"If everyone only accepted packets from those they trust, and applications were infinitely secure, there would be no need for advanced routing methodology!".
I can now say with absolute confidence that you are not a network engineer, or even very knowledgeable on the topic.
DNS is a reasonable example of a distributed application with redundancy baked in. SMTP and HTTP are common examples of epic fail in this regard which is just awesome for everyone in the business of selling load balancers.
Funny you mention that, since the DNS infrastructure is nothing but a massive mix of anycast routing and load balancers. DNS isn't inherently distributed at nearly the scale it needs to be to handle this many users. We did that for you, at the network layer. You're welcome. Furthermore, unless you're talking about turning it into some insane global torrent like reachability hash with terrible reachability heuristics, that isn't set to change any time soon.
If only parking lots were suitably engineered, we wouldn't need stop lights, onramps, freeways, or anything else.
No, I'm sorry. You're flat out wrong.
The problem with all of your musing, is that it's simplified to the point of impossibility- possibly absurdity. It ignores the reality of the system for the sake of idealism. "If only it were more ideal, then I'd be right!"
It never has been, and it never will be. I'm sorry. This is no longer an applied discussion, it's a philosophical one, on par with a religious debate.
You're completely correct. Generally, a router will fragment unless the DF flag is set.
This of course leads to truly craptastic performance, but prevents you from what appears to be anomalous connection stalls after the connection handshakes and sends some basic headers. Most commonly, it's seen as a web request where the client successfully sends a GET, but never gets a reply.
When the router is fragmenting for you, you get the awesome scenario where you have one packet that turns into a full MTU packet, and a packet consisting of another full IP header and a few bytes of data. This still "works" for some people, so they think what they're doing is ok, and they just try to throw hardware at their shit performance without understanding why they need bigiron to push a gigabit of traffic.
At least in Ubuntu, the rc-local.service unit exists. It's enabled by default, but you have to create/etc/rc.local and mark it executable.
It's been a while since I used debian proper, so I don't know if that's the case that... But I suspect the unit file is probably part of the default systemd distribution.
It's a funny thing. Ethernet interfaces have been able to have multiple IPv4 addresses assigned to them for like _forever_. It's always boggled my mind that ifconfig has required you to go through this bullshit "interface aliasing" song and dance to do what's a one-liner in 'ip'.
This is actually because net-tools was written to target linux 2.0
At that time, interface aliases were the only way to accomplish an IP alias (IOCTL interface doesn't allow for adding a layer-3 alias to an interface)
When RTNL was made, circa Linux 2.2, that added support for layer-3 aliases to existing interfaces, and thus began the divergence between net-tools, and the Linux kernel's network stack, and the advent of iproute, and subsequently iproute2.
So yes, the core architecture of net-tools is from Linux 2.0. And therein lies our problem, and the reason this is all happening.
That comparison isn't apt at all, though. The iproute2 tools show all information net-tools show, and much, much, much more.
Your complaint seems to be that you can't type ifconfig.
They in this instance is between you and your distribution maintainers.
As I've stated many times, iproute is a very old package. It's from 1996. It was never made to supplant anything. It was only through literal decades of neglect on the part of the net-tools maintainers that distributions started switching over to iproute2.
iproute2 doesn't try to emulate net-tools behavior, because it was never designed to be a replacement. It was simply designed to be a tool that handled all the functionality of the RTNL interface.
No. I'm one of those people who builds the networks that all of your services run on today, while you man a help desk in Wisconsin and opine on slashdot about things out of your league.
Standards to exist for a reason. Please cite the ones violated, here;)
I began using it about 10 years back when developing a linux-based routing and shaping platform to replace our aging Netscreens for a 3000-residence gigabit fiber community.
The things I needed to do then still can't be done with net-tools today, in terms of routing or traffic shaping. I knew back then that iproute2 would eventually completely displace net-tools... I also knew the sysadmins with more mundane use cases for Linux would scream bloody murder. I'm actually amazed it took this long.
Well the good news for you then, is that iproute has been in development, and shipped by default in every major distribution since 1996.
Every single distribution I use, (and I'm told slackware as well) rely upon iproute2 for their basic system network management scripts,
and as of the most recent release of CentOS/RHEL, net-tools aren't even installed by default anymore. You can of course still install them if you like them. You won't be able to fully utilize the capabilities of the linux kernel in the networking domain, but you likely don't care about that if you don't know the history of iproute/iproute2.
ip -s addr
I'll grant you it's definitely not as visually appealing as ifconfigs output.
BTW, RHEL7 uses systemd... and/etc/rc.local works just fine. You have to set it executable first, though.
It's execution is provided for by the rc-local.service unit.
Yes. Someone should go back to 1996 when these tools were first written and introduced into fucking debian to implement an obscure linux kernel interface that ended up becoming the official and preferred kernel interface for dealing with the networking stack, punch the net-tools guys for refusing to support said interface for the next *two fucking decades*, while every major distribution slowly moved their network management scripts over to it, and then punch 16 year old poettering in the face for some day writing another tool that everyone hates.
And someone modded your ass insightful. Amazing.
Which does a great job of demonstrating just what is wrong with the way net-tools does things. Net-tools can *only* sequentially list the entire routing table (because that's how it receives it from/proc). This gets really ugly on AS edge routers. There's nothing inherently wrong with using the "route" command. It's simply that its authors (net-tools) for linux, refuse to implement RTNL support to modernize the capabilities of the programs.
I find it humorous that you say this.
iproute and iproute2 came into existence because Linux switched from IOCTLs for managing the network stack to RTNL. The net-tools authors were uninterested in implementing RTNL, so a new tool had to be written (or the old one forked and modified)
iproute started out as a single-purpose tool to modify the RPDB, which was only exposed via RTNL. As the kernel developers eventually added *everything* network management related to RTNL, the tool expanded to use those features. 2 decades later, the net-tools authors still refuse to use the RTNL interface. They're stuck with the functionality they get via IOCTL and/proc.
Thank you for inserting your grossly misinformed opinion into the discussion, though.
A CDS is MAC. Turning off ICMP toward people who aren't allowed to access your node/network is understandable. They can't get anything else though, why bother supporting the IP control channel? CDS does *not* say turn off ICMP globally. I deal with CDS, SSAE16 SOC 2, and PCI compliance daily. If your CDS solution only operates with a layer-4 ACL, it's a pretty simple model, or You're Doing It Wrong (TM)
Nope. Kernel authors come up with fancy new netlink interface for better interaction with the kernel's network stack. They don't give two squirts of piss whether or not a user-space interface exists for it yet. Some guy decides to write an interface to it. Initially, it only support things like modifying the routing rule database (something that can't be done with route) and he is trying to make an implementation of this protocal, not try to hack it into software that already has its own framework using different APIs.
This source was always freely available for the net-tools guys to take and add to their own software.
Instead, we get this.
Nobody is giving a positive spin. This is simply how it happened. This is what happens when software isn't maintained, and you don't get to tell other people to maintain it. You're free, right now, today, to port the iproute2 functionality into net-tools. They're unwilling to, however. That's their right. It's also the right of other people to either fork it, or move to more functional software. It's your right to help influence that. Or bitch on slashdot. That probably helps, too.
The only service necessary for a network to provide is to get some predefined quantity of packets with some probability of success from point A to point B.
Sure. Absolutely. It's not like you slap "B" on the packet and it magically flies there, amigo.
In the middle, is routing. At its simplest, simply a shortest length prefix match and a next hop. At more complicated levels, distributed switching, VPN/Labeling protocols, layer-4 switching, IPVS/load balancing, anycast routing.
It absolutely is especially across administrative domains. Only packets are not isolated. Data and access to that data using means a heck of a lot more secure then what passes for management plane of most "carrier grade" networks are used.
What? This is nonsensical. Only packets are not isolated? What else is there but packets?
Perhaps the carrier grade networks of the world should employ you, so that you can show us what we're doing so wrong. Last I checked, we keep about 750,000 prefixes and close to 100,000 entirely autonomous networks connected with our shitty control planes.
If I understand you correctly, you propose that as an alternative to protected networks and blocking packets, we should rely on the application? Can you really not see why that is ridiculous and wasteful? It sounds to me like you are proposing that there is no such thing as a secure network. This is beyond stupid.
Yes, applications are the only things anyone cares about. Nobody cares about wires and packets nor should they
Erm... Again, how the fuck do you think the data gets to you?
Do you think high availability and scaling to millions of users comes from simple routing tables running on netgears?
How about office virtualized networks across metro areas (and further)?
You... are killing me, smalls.
When people waste time trying to add "security, application availability, isolation and management regimes" to networks they only get more complex for no reason and as a result the probability of successful delivery of packet from point A to point B is diminished or at least a lot more expensive than it otherwise would given the same investment in capability.
From a simple architectural standpoint, things like "application availability" absolutely must be done at the network layer, unless you've got some serious magic tricks up your sleeves. Computers die, network-based attacks happen at protocol or application layers, networking equipment dies. Oh, I know... We can just use client-side redundancy and have 112,554 A records for a name. That'll work.
Please don't misunderstand what I'm saying. It's not that if I were in your shoes I would do anything any differently. We all must live within the context of our time. I'm not saying your wrong or course of action isn't rational and logical. It's just that it's architecturally very much a dead end.
It isn't though, and you can't back up that assertion.
Complexity is not automatically bad.
KISS doesn't mean make it simple beyond what it takes to do the job. It means do the job as simple as possible. And architecturally, that's largely what we do.
The raw scale of what we must do these days requires magic at the network layer. It's frankly a miracle it's as clean as it is, and it gets cleaner every day. Where once we used dirty VLAN trunking everywhere for network isolation, we now use layer-3 guided label switching (MPLS/VPLS).
If someone wants a private network that I carry around for them, i have VRF.
If I need a machine that can communicate out 6 different networks with different gateways, I have PBR.
The applications have become more demanding than I think you realize.
This is not about someone needing to spin up a VM for some immediate need. It's about WHY they felt they needed to do that in the first place. What was it that they were trying to do? For the most part people want to manage s
Slashdot Mirror
and take a good chunk of the gaming GPU market away from both Nvidia and AMD in 2019/2020
LOL. No.
The fledgeling hardware raytracing movement is cool to watch, but it's nowhere near replacement of rasterization. Even now it exists as a hybrid solution with numerous enough problems that adoption is nil.
Ultimately, it's game developers that will drive hardware raytracing. Awesome hardware without the game industry targeting your hardware leads to dead ends. How *is* your 3dfx gpu doing, anyway?
The IDE is cluttered, gets in the way and is painful to use. It is tedious
That's like, your opinion, man. And a minority opinion, at that.
I have to hardcode options, I can't use discovery tools to see what exists or where it is. As an autoconf/cmake replacement, it sucks.
Good god. You still use autoconf?
It's slow. Given the choice of VS or Emacs, I would use Emacs every time. Much less overhead, much more real estate.
Yes, and you'll never get a real job as a programmer. I love Emacs too. I use it for all of my scripting, and even small and simple linux C projects. Emacs isn't even an IDE when compared to the IDE functionality of VS. It's a really bitchin extensible text editor with some language punctuation and highlighting features. I'm beginning to wonder if you're even serious, here.
And that's central to an IDE, your real estate. It's mostly wasted in VS, no matter what you do.
Yawn. Your real estate is what is central to your IDE? I'm starting to piece something together here. What you need is a text editor. I'm wondering if you're really qualified to be forming opinions about what makes a good IDE when you're quite clearly an amateur.
Auto builds slow the computer down and are a bad design choice.
Again, are you serious? I don't know whether to attack the literal falsity of that, or the obvious solution to it.
Probably the best IDE I have ever seen for any language on Windows was Borland Turbo Pascal 3's. The Inmos folding editor was superb, Ada's GPS and Eiffel's GUI are decent. Vi and Notepad++ are brilliant (tools should never get in the way). Really, for programming help, Norton Guides were the best I've ever seen.
TP3 and BCB were both good products. Very similar to VS, but in a lot of ways better. But still, everything that you love about them, you hate about VS. Weird.
As for the rest of that horseshit, again... with the text editors. I'm sorry VS has too much functionality for you. I'm sorry you work on simple software projects, and are confused a lot of tools in your face. That's fine. Stick to your text editors, and the professionals will continue to use professional tools.
Next up, jd tells us about using Gimp for professional post processing.
Their debugger is dreadful. If that's the best you've used, I pity you. I don't use it, even if using VS.
Again, that's like, your opinion, man. And you're again a minority. But yes, using GDB is a fucking thrill [rolls eyes]
Indeed, I think you'll find Notepad++ beats VS in popularity.
Mmmh, no. As a text editor? Sure. Probably. VS is a little heavy for simply editing files. It is, after all, a fucking IDE- something that notepad++ *is not*.
More people might own VS with Windows but that's because you can't separate it from the compiler and most competing compilers oblige you to install VS even if you never use it. That's not popularity, that's antitrust.
Poppycock. You can develop for windows without VS. Furthermore, you can separate VS from the compiler as well. Hell, you can use GCC if you want. It's just a fucking IDE. It also, unsurprisingly, ships with compilation and linking tools, derp.
I'd love to start picking apart all the ways your selected software sucks, but not a single fucking one of them were an IDE, so I'm kind of at a loss here. Since they are pretty good text editors, I can't really shit on them too badly. What I can say, is you didn't have a single good point, your opinion is not only a minority one, but also ridiculously bone headed. And finally, you need to look up the definition of antitrust.
Na. They have pretty great development tools.
Now if you want to get into the specific performance and idiosyncrasies of their compiler, I'm on board.
Their IDE however is world-class, and earns its spot as the most popular IDE in use. Their debugger is also the nicest debugger I have ever used.
Your arguments are pretty lame, really. You list a bunch of niches that Microsoft apparently doesn't care about or attempt to compete in, and say that's why they rate poorly.
You suck because you've never gotten a medal in the special olympics.
Yes, I am in fact the idiot who has been written about in 3 books, invited to speak at a security convention regarding embedded linux kernel attacks, runs 14 DNS servers, and a network serving approximately 10,000 residential and business customers. The idiot who was also categorically correct, as evidenced by your own infallibility metric- whether or not Poettering conceded he was a moron and fixed the problem. You know what now resolves DNS hostnames with underscores? systemd-resolved.
Good luck learning computers, indeed. Enjoy spreading your ignorance across the internet on the backs of people like me, you dim-witted ingrate.
Get out of your basement. Get some sun. And maybe an education, or at the very least some lessons in humility.
If your grasp of other technical systems is a shit ass poor as your grasp of reading RFCs and DNS, then I doubt you get anything done "IRL" other than keeping your mom's computer running.
Yes, it was a joke. I'm however not even remotely surprised that you were too thick to get it.
Sure did! It was an attempt at humor by pointing out a paradox. I'm actually amazed you were able to find enough time out of being wrong about almost everything you say to notice! Congrats, ZK. You're almost not useless
Not that I see eye to eye with you in any way, shape or form, but after seeing his posts on the iproute2 discussion, he isn't qualified to offer an opinion on anything Linux related.
I can now say with absolute confidence that you are not a network engineer, or even very knowledgeable on the topic.
DNS is a reasonable example of a distributed application with redundancy baked in. SMTP and HTTP are common examples of epic fail in this regard which is just awesome for everyone in the business of selling load balancers.
Funny you mention that, since the DNS infrastructure is nothing but a massive mix of anycast routing and load balancers. DNS isn't inherently distributed at nearly the scale it needs to be to handle this many users. We did that for you, at the network layer. You're welcome. Furthermore, unless you're talking about turning it into some insane global torrent like reachability hash with terrible reachability heuristics, that isn't set to change any time soon.
If only parking lots were suitably engineered, we wouldn't need stop lights, onramps, freeways, or anything else.
No, I'm sorry. You're flat out wrong.
The problem with all of your musing, is that it's simplified to the point of impossibility- possibly absurdity. It ignores the reality of the system for the sake of idealism. "If only it were more ideal, then I'd be right!"
It never has been, and it never will be. I'm sorry. This is no longer an applied discussion, it's a philosophical one, on par with a religious debate.
You're completely correct. Generally, a router will fragment unless the DF flag is set.
This of course leads to truly craptastic performance, but prevents you from what appears to be anomalous connection stalls after the connection handshakes and sends some basic headers. Most commonly, it's seen as a web request where the client successfully sends a GET, but never gets a reply.
When the router is fragmenting for you, you get the awesome scenario where you have one packet that turns into a full MTU packet, and a packet consisting of another full IP header and a few bytes of data. This still "works" for some people, so they think what they're doing is ok, and they just try to throw hardware at their shit performance without understanding why they need bigiron to push a gigabit of traffic.
At least in Ubuntu, the rc-local.service unit exists. It's enabled by default, but you have to create /etc/rc.local and mark it executable.
It's been a while since I used debian proper, so I don't know if that's the case that... But I suspect the unit file is probably part of the default systemd distribution.
It's a funny thing. Ethernet interfaces have been able to have multiple IPv4 addresses assigned to them for like _forever_. It's always boggled my mind that ifconfig has required you to go through this bullshit "interface aliasing" song and dance to do what's a one-liner in 'ip'.
This is actually because net-tools was written to target linux 2.0
At that time, interface aliases were the only way to accomplish an IP alias (IOCTL interface doesn't allow for adding a layer-3 alias to an interface)
When RTNL was made, circa Linux 2.2, that added support for layer-3 aliases to existing interfaces, and thus began the divergence between net-tools, and the Linux kernel's network stack, and the advent of iproute, and subsequently iproute2.
So yes, the core architecture of net-tools is from Linux 2.0. And therein lies our problem, and the reason this is all happening.
That comparison isn't apt at all, though. The iproute2 tools show all information net-tools show, and much, much, much more.
Your complaint seems to be that you can't type ifconfig.
They in this instance is between you and your distribution maintainers.
As I've stated many times, iproute is a very old package. It's from 1996. It was never made to supplant anything. It was only through literal decades of neglect on the part of the net-tools maintainers that distributions started switching over to iproute2.
iproute2 doesn't try to emulate net-tools behavior, because it was never designed to be a replacement. It was simply designed to be a tool that handled all the functionality of the RTNL interface.
No. I'm one of those people who builds the networks that all of your services run on today, while you man a help desk in Wisconsin and opine on slashdot about things out of your league. ;)
Standards to exist for a reason. Please cite the ones violated, here
I began using it about 10 years back when developing a linux-based routing and shaping platform to replace our aging Netscreens for a 3000-residence gigabit fiber community.
The things I needed to do then still can't be done with net-tools today, in terms of routing or traffic shaping. I knew back then that iproute2 would eventually completely displace net-tools... I also knew the sysadmins with more mundane use cases for Linux would scream bloody murder. I'm actually amazed it took this long.
Well the good news for you then, is that iproute has been in development, and shipped by default in every major distribution since 1996.
Every single distribution I use, (and I'm told slackware as well) rely upon iproute2 for their basic system network management scripts,
and as of the most recent release of CentOS/RHEL, net-tools aren't even installed by default anymore. You can of course still install them if you like them. You won't be able to fully utilize the capabilities of the linux kernel in the networking domain, but you likely don't care about that if you don't know the history of iproute/iproute2.
ip -s addr /etc/rc.local works just fine. You have to set it executable first, though.
I'll grant you it's definitely not as visually appealing as ifconfigs output.
BTW, RHEL7 uses systemd... and
It's execution is provided for by the rc-local.service unit.
Yes. Someone should go back to 1996 when these tools were first written and introduced into fucking debian to implement an obscure linux kernel interface that ended up becoming the official and preferred kernel interface for dealing with the networking stack, punch the net-tools guys for refusing to support said interface for the next *two fucking decades*, while every major distribution slowly moved their network management scripts over to it, and then punch 16 year old poettering in the face for some day writing another tool that everyone hates.
And someone modded your ass insightful. Amazing.
More than 20, apparently.
Which does a great job of demonstrating just what is wrong with the way net-tools does things. Net-tools can *only* sequentially list the entire routing table (because that's how it receives it from /proc). This gets really ugly on AS edge routers. There's nothing inherently wrong with using the "route" command. It's simply that its authors (net-tools) for linux, refuse to implement RTNL support to modernize the capabilities of the programs.
I find it humorous that you say this. /proc.
iproute and iproute2 came into existence because Linux switched from IOCTLs for managing the network stack to RTNL. The net-tools authors were uninterested in implementing RTNL, so a new tool had to be written (or the old one forked and modified)
iproute started out as a single-purpose tool to modify the RPDB, which was only exposed via RTNL. As the kernel developers eventually added *everything* network management related to RTNL, the tool expanded to use those features. 2 decades later, the net-tools authors still refuse to use the RTNL interface. They're stuck with the functionality they get via IOCTL and
Thank you for inserting your grossly misinformed opinion into the discussion, though.
A CDS is MAC. Turning off ICMP toward people who aren't allowed to access your node/network is understandable. They can't get anything else though, why bother supporting the IP control channel? CDS does *not* say turn off ICMP globally. I deal with CDS, SSAE16 SOC 2, and PCI compliance daily. If your CDS solution only operates with a layer-4 ACL, it's a pretty simple model, or You're Doing It Wrong (TM)
Nope. Kernel authors come up with fancy new netlink interface for better interaction with the kernel's network stack. They don't give two squirts of piss whether or not a user-space interface exists for it yet. Some guy decides to write an interface to it. Initially, it only support things like modifying the routing rule database (something that can't be done with route) and he is trying to make an implementation of this protocal, not try to hack it into software that already has its own framework using different APIs.
This source was always freely available for the net-tools guys to take and add to their own software.
Instead, we get this.
Nobody is giving a positive spin. This is simply how it happened. This is what happens when software isn't maintained, and you don't get to tell other people to maintain it. You're free, right now, today, to port the iproute2 functionality into net-tools. They're unwilling to, however. That's their right. It's also the right of other people to either fork it, or move to more functional software. It's your right to help influence that. Or bitch on slashdot. That probably helps, too.
Most likely my unclean shutdowns weren't so predominantly during updates like yours were. That's good to know, though.
The only service necessary for a network to provide is to get some predefined quantity of packets with some probability of success from point A to point B.
Sure. Absolutely. It's not like you slap "B" on the packet and it magically flies there, amigo.
In the middle, is routing. At its simplest, simply a shortest length prefix match and a next hop. At more complicated levels, distributed switching, VPN/Labeling protocols, layer-4 switching, IPVS/load balancing, anycast routing.
It absolutely is especially across administrative domains. Only packets are not isolated. Data and access to that data using means a heck of a lot more secure then what passes for management plane of most "carrier grade" networks are used.
What? This is nonsensical. Only packets are not isolated? What else is there but packets?
Perhaps the carrier grade networks of the world should employ you, so that you can show us what we're doing so wrong. Last I checked, we keep about 750,000 prefixes and close to 100,000 entirely autonomous networks connected with our shitty control planes.
If I understand you correctly, you propose that as an alternative to protected networks and blocking packets, we should rely on the application? Can you really not see why that is ridiculous and wasteful? It sounds to me like you are proposing that there is no such thing as a secure network. This is beyond stupid.
Yes, applications are the only things anyone cares about. Nobody cares about wires and packets nor should they
Erm... Again, how the fuck do you think the data gets to you?
Do you think high availability and scaling to millions of users comes from simple routing tables running on netgears?
How about office virtualized networks across metro areas (and further)?
You... are killing me, smalls.
When people waste time trying to add "security, application availability, isolation and management regimes" to networks they only get more complex for no reason and as a result the probability of successful delivery of packet from point A to point B is diminished or at least a lot more expensive than it otherwise would given the same investment in capability.
From a simple architectural standpoint, things like "application availability" absolutely must be done at the network layer, unless you've got some serious magic tricks up your sleeves. Computers die, network-based attacks happen at protocol or application layers, networking equipment dies. Oh, I know... We can just use client-side redundancy and have 112,554 A records for a name. That'll work.
Please don't misunderstand what I'm saying. It's not that if I were in your shoes I would do anything any differently. We all must live within the context of our time. I'm not saying your wrong or course of action isn't rational and logical. It's just that it's architecturally very much a dead end.
It isn't though, and you can't back up that assertion.
Complexity is not automatically bad.
KISS doesn't mean make it simple beyond what it takes to do the job. It means do the job as simple as possible. And architecturally, that's largely what we do.
The raw scale of what we must do these days requires magic at the network layer. It's frankly a miracle it's as clean as it is, and it gets cleaner every day. Where once we used dirty VLAN trunking everywhere for network isolation, we now use layer-3 guided label switching (MPLS/VPLS).
If someone wants a private network that I carry around for them, i have VRF.
If I need a machine that can communicate out 6 different networks with different gateways, I have PBR.
The applications have become more demanding than I think you realize.
This is not about someone needing to spin up a VM for some immediate need. It's about WHY they felt they needed to do that in the first place. What was it that they were trying to do? For the most part people want to manage s