Announcement

Collapse
No announcement yet.

systemd devs want to fork the kernel

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    systemd devs want to fork the kernel

    Found this analysis of the situation:

    http://distrowatch.com/weekly.php?is...0330#community

    Wish I could be a fly on the wall in Linus' office...
    Kubuntu 23.11 64bit under Kernel 6.8.8, Hp Pavilion, 6MB ram. All Bow To The Great Google... cough, hack, gasp.

    #2
    https://github.com/systemdaemon


    Ivan......Gotyaovoich?


    /me suspects a joke

    Comment


      #3
      I guess it's already 1st April in some parts of the world?
      samhobbs.co.uk

      Comment


        #4
        Indeed. It amazes me how quickly nerds and geeks forget this day, and usually fall to some gag or other.

        Obligatory list: http://en.wikipedia.org/wiki/April_F...t_for_Comments

        Haha, I just noticed RFC 6214, which is an update of the classic RFC 1149 for IPv6.

        5. Routing and Tunneling Considerations

        Routing carriers through the territory of similar carriers, without peering agreements, will sometimes cause abrupt route changes, looping packets, and out-of-order delivery. Similarly, routing carriers through the territory of predatory carriers may potentially cause severe packet loss. It is strongly recommended that these factors be considered in the routing algorithm used to create carrier routing tables. Implementers should consider policy-based routing to ensure reliable packet delivery by routing around areas where territorial and predatory carriers are prevalent.

        There is evidence that some carriers have a propensity to eat other carriers and then carry the eaten payloads. Perhaps this provides a new way to tunnel an IPv4 packet in an IPv6 payload, or vice versa. However, the decapsulation mechanism is unclear at the time of this writing.

        6. Multihoming Considerations

        Some types of carriers are notoriously good at homing. Surprisingly, this property is not mentioned in RFC 1149. Unfortunately, they prove to have no talent for multihoming, and in fact enter a routing loop whenever multihoming is attempted. This appears to be a fundamental restriction on the topologies in which both RFC 1149 and the present specification can be deployed.

        7. Internationalization Considerations

        In some locations, such as New Zealand, a significant proportion of carriers are only able to execute short hops, and only at times when the background level of photon emission is extremely low. This will impact the availability and throughput of the solution in such locations.

        8. Security Considerations

        The security considerations of [RFC1149] apply. In addition, recent experience suggests that the transmission elements are exposed to many different forms of denial-of-service attacks, especially when perching. Also, the absence of link layer identifiers referred to above, combined with the lack of checksums in the IPv6 header, basically means that any transmission element could be mistaken for any other, with no means of detecting the substitution at the network layer. The use of an upper-layer security mechanism of some kind seems like a really good idea.
        Last edited by SteveRiley; Mar 30, 2015, 08:37 PM.

        Comment


          #5
          Originally posted by SteveRiley View Post
          Indeed. It amazes me how quickly nerds and geeks forget this day, and usually fall to some gag or other.
          In all fairness, it gets easier to fall for one when they are released a few days of the mark.

          Comment

          Working...
          X