nenolod

That depends on that software being deployed in a timely manner. There's plenty of instances out there still on Mastodon 1.6 and 2.0 because the admin installed it 2 years ago and hasn't updated since.

Actually a hybrid approach is the way. Nobody wants to wait hours to download GBs of new gossip to get started. Streaming the gossip is necessary to make the technology viable.

Mastodon at Twitter scale could be truly hilarious to see.

A few of the people in that group (but none on the technical board) have been contributing to projects and then disappear once the IRCv3 bits are included. Thusly it appears from a broad glance that they had no interest in the project itself as much as getting another client onboarded with IRCv3 support.

This in combination with the marketing efforts of the IRCv3 group places large amounts of pressure to just accept and maintain the patch in order to ensure that you wind up on their list of recommended software to use, instead of their advocacy of using a different software which has added the patches.

Regarding the IRCv3 group: it's actually worse.

Historically the IRCv3 project originated at Atheme as a project to bring some extensions to IRC in order to make it more modernized, such as the SASL binding (IRC Authentication Layer). ZNC guys and Atheme guys did not get along because political reasons, so they threatened to fork the project. Atheme decided to spin off the IRCv3 project at that time as it was no longer really interesting to Atheme anyway (IAL was adopted in basically every IRCd and most mainstream clients).

While I cannot really comment on the current managerial processes of the project (as I do not know what internal discussions the technical board has anymore, if any), the technical board allows people to submit things that they know will never ever be ratified, without saying what the outcome will be when it is already known to them, in order to give the appearance that they are an open project. In fact, advising people to not work on specifications that mainstream vendors will not adopt is actively discouraged by the working group, as the image of being open and the appearance of being non-offensive is more important than discouraging people from wasting their time.

As for charybdis (a widely deployed IRC server): we keep an eye on the IRCv3 group and implement things that we find interesting. There is no commitment from us to implement future IRCv3 work just because it is an IRCv3 specification.

As for IRC itself: IRC is a wonderful thing, but honestly in 2016 we can do much better. The backwards compatibility requirement of IRCv3 (which exists because they do not feel they have enough influence yet) is a serious crutch that prevents a lot of potential work for fixing design problems with IRC. The lack of unique identifiers at the client level (other than nickname) makes a lot of things like nickname ownership painful. The overall concept of IRC is a powerful one, but the technical foundation is crap. This is why Slack, gitter.im, etc are kicking IRC's ass right now, and IRCv3 is honestly too little too late for that fight. These services offer easy integration with any type of website and the IRCv3 group is too busy talking about bringing HSTS to IRC. This is a total and complete inversion of priorities verses where they should be.

Interesting but the article does not really explain the thesis statement at all...

It's very specialized and last time I looked at it, it was based on Qt types and other ugly things. It would not be realistic as an alternative protocol for IRC itself.

It sends some channel messages after the JOIN. The new IRCv3.2 specification (being formally ratified across vendors soon!) adds a BURST type to make the protocol transactional which will allow displaying the messages in the right order with a little bit of work on the client side.

We are planning to bring some experimental JSON-based transport for 3.3 which will allow us to eventually start transitioning to considering IRC events in an intermediate representation. The key thing is going to be getting the client authors to understand the benefits of this approach, as well as providing implementation of both the extended RFC1459 payload format and the JSON format.

The eventual end game is to have a flag day and deprecate the legacy format, but this will probably take a few years to do.

None.

His business model is, he has a bunch of cabinets colocated in a datacenter I operate in Dallas.

And he financed it with his bitcoin winnings, I guess.

This has layer3 properties, such as connection rate, and was most likely mitigated using layer 3 filtering.

Direct peering with the eyeball networks helps a lot, as you can use smaller links (and thus, smaller scrubbing devices) on them. I do not believe that it sacrifices network neutrality, really.

Comcast is really in a class of it's own regarding one-sided peering policies, but the other providers like Cox for example are fairly easy to peer with.

The Github attack was a volumetric flood, this most certainly has layer 3 properties.

The post clearly discusses layer7 floods which do not have layer3 properties (such as slowloris.pl, rudy.pl, etc.) which are uncommon.

It would be a safe bet to say that the Github attack had layer-3 properties.

Usually it's some kid who wants to show off their botnet (or, more likely their $5 booting service investment) to their friends on hackforums.

I deal with this crap all the time.

Actually, this is not really true.

Writing a fully-fledged RFC1459 parser that handles all potential corner-cases in a secure and efficient manner is actually very difficult. By moving the essence of the protocol to an encapsulation that is based on JSON, it can be parsed with already proven JSON libraries.

As an example, the bug which crashed EFnet at the end of 2012 was caused by an unanticipated side-effect in the way RFC1459 messages are formed. Ratbox is a server which has benefited from the work of many experts on parsing RFC1459, and yet the bug was still there.

A simple JSON representation maintains the serviceability of using telnet as a client, but the proposals made on the bug were ridiculous. Either way, you guys trashed it so it gets buried for now.

BuyVM.

http://lowendtalk.com/discussion/20847/buyvm-lies-cheats-ste...

Whether they are doing so dishonestly is a subjective question though. I changed the README a little.

The point here is that the information in /proc/cpuinfo is virtualized, and therefore may not reflect reality...

This is more about the "I put a VPS inside your VPS" situation, which is common amongst the providers offering Virtuozzo at budget pricing.

In that case, we do not have files in /proc to look at, we have to do it the hard way instead.

The point of the project in this case is to detect the hypervisor from within a child container (which has a virtualized /proc and /sys).

Hosting providers do this with their Virtuozzo products so they can take advantage of memory deduplication. Such information can be helpful in diagnosing performance bottlenecks (think paravirtual steal-time).

Honestly the usage of SolusVM, WHMCS etc (i.e. things written in PHP which have no business being written in at least, the way a PHP typically is written) has been the main security problem of the entire industry.

We need more things like OpenStack out there -- competently designed and implemented toolstacks that actually work correctly and have a remotely acceptable security model.

Alpine 2.4, 2.5 and 2.6 are not vulnerable even though PERF_EVENTS is enabled:

    [5126545.172128] BUG: unable to handle kernel paging request at ffffffff1de68048

Lets be honest here. How frequently do you think a company changes processors?

Since Dodd-Frank, debit cards and credit cards have the same liability protections.

Proof?

Last 4 is all you need to wreak some serious havoc though. Service cancellations and whatnot...

Except that LISH passwords were plaintext...

Unfortunately it is tied to the merchant. :(

Except you know, system memory when the key material is unlocked... unless you really believe someone is sitting there typing in the passphrase for each non-batch CC transaction, because I do not.

The problem is that Linode is not anywhere near the "most transparent company out there."