kloch

Most of the first CD's in the 80's were made straight from the masters engineered for Vinyl and Casette media. They sounded awful with absurdly excessive EQ in the 3-6KHz range. Non-technical people commented that they preferred Vinyl because they could "hear the Aluminum" in CD's.

This was eventually fixed and proper CD masters started to become common in the early 90's.

Another thing to consider is the natural aging of our ears. Even without abuse high frequency sensitivity degrades as we get older. Those 80's CD's probably don't sound as harsh to someone 40+ today as they did back then.

Multipliers for other widths: https://www.pcg-random.org/posts/does-it-beat-the-minimal-st...

Strict URPF cannot be applied to any customer that might be multihomed, which rules out any BGP customer or peer.

The reason is that multi-homed networks are not required to, and often do not advertise the same routes to all of their BGP peers. This may be done for routing policy purposes, traffic engineering, or simply to mitigate a temporary performance problem/outage with one of your transit providers/peers.

This means that strict URPF has to be deployed on the many networks that are close to statically routed end users. However, even statically routed customers could be multihomed and send traffic asymmetrically. This is not common but could cause headaches for support - even if you make an exception it could get accidentally overridden in the future.

On my networks (data center/hosting) we configure strict URPF on statically routed customers by default but not for BGP customers.

My ad-free/JavaScript-free IP address lookup: ip4.me / ip6.me

You joke but I found this interesting (from https://en.wikipedia.org/wiki/Metal_oxide_semiconductor):

> It is the basic building block of modern electronics, and the most frequently manufactured device in history, with an estimated total of 13 sextillion (1.3×10^22) MOSFETs manufactured between 1960 and 2018

64 bits can address 1.8x10^19 bytes. Of course there is not a 1:1 correlation between mosfets ever made and bytes of ram usable today but it's curiously close to the 64-bit limit so you could say 64 bits is just enough to address every byte in the world.

I wonder how much magnetic storage would add to that?

so that is why they say before every single flight "Make sure you download the United app before takeoff as you will not be able to download it in the air".

Very nice!

Now it needs an algorithm to detect related stories across different sites so they can have their own “popular stories” section or ignored after you have browsed them.

This was a real problem until US Gov mandated "PRND" shift order, among other things.

Now, if they could just make the windshield wiper controls all work the same direction...

> I wonder why he doesn't do a crowd funding, I am sure he would raise the money easily

At first this seems like a non-starter because it's a for-profit film so soliciting donations might be a hard sell. If it were advertised as pre-sale where you are basically buying a copy of the film before it's made, it might work. Still, $120M is a lot of pre-sales and you would be on the hook for refunds if the film were never completed.

Actual equity investors in motion pictures entitled to a share of the profits have to be "accredited", at least in the US. You can't solicit investments from the general public. https://en.wikipedia.org/wiki/Accredited_investor. You also wouldn't want a huge number of investors, that's a lot of paperwork.

I always used BSD for servers when it is an option. Linux distros are frustratingly different from classic BSD/SysV for seemingly no good reason while FreeBSD is "just right" for me. Same for OS X historically on workstations/laptops. I've tried many times to get FreeBSD working well on laptops but since all of my laptops are macs that has been unworkable.

My biggest problem with OS X in recent years is the process bloat. Mountain Lion was the last "clean" version to have a reasonable number of OS processes running, now it's in the mid hundreds (!) It's not just resource usage, it's the attack surface/telemetry leakage. I only want the absolute minimum processes running and FreeBSD still gives me that.

> Performance approaching that of statically-typed languages like C

I might have to give this a try. Is there any language other than assembly that can beat the performance of C?

While Lat/Lon (or Lon/Lat) is intuitive, it is not an ideal system for addressing a location on a 2-sphere. It has uneven Longitude width vs Latitude and discontinuities at the poles. I wonder what system we would use if the poles were densely populated.

> Well worth reading because some exchange will likely go bankrupt eventually!

This has already happened on a massive scale with MtGox in Japan. That unwind closely resembled a traditional corporate bankruptcy liquidation. Many other smaller exchanges have failed in a disorderly manner due to hacks and exit scams.

Not all exchanges are completely unregulated. US based exchanges all fall under scrutiny of "money transmitter" regulators. Coinbase is also regulated as a digital asset company by New York. Coinbase mentions in their TOS that USD deposits are kept in FDIC insured accounts kept separate from corporate funds. Their Crypto assets are not segregated however, which is surprising.

I think the term "effectively stable" is what is meant in this context.

I'm not speaking for ARIN but their CEO John Curran told me ARIN has never revoked address resources for any reason other than non-payment or fraud. As long as your original application for the resources was made in good faith and you continued to pay the registration fees, they would not take them away even if you are not using them anymore. This seems logical for functional IPv4 markets where the non-use/non-need is explicit in any resource being offered for sale. The registered organization does still need to be "in business" (registered in good standing with the state corporation commission or equivalent). If the entity is dissolved then the resources automatically revert back to ARIN and it may be difficult or impossible to sell to a third party.

It is important to keep ARIN updated with any organization name changes, reorganization, or M&A actions as they happen. Going back 10+ years to update those changes, especially if there are several, can be extremely difficult. In large companies the network folks that manage ARIN resources are often not even be aware of those changes until they interact with ARIN again. That has bitten me several times in my career.

In the old days before IPv4 runout they could and would refuse to issue additional IP blocks if you did not show sufficient utilization of your most recent allocation. It was also not unusual for them to reduce the allocation size requested based on how fast you had utilized your most recent block.

Software engineers seem to have a lot of problems with trigonometry and especially spherical coordinates/rotations. One recent example is MS FS2020 which despite being a clean-sheet redesign is still unable to render correctly or fly near the poles.

Quaternions are popular because they are usually the fastest technique but are notoriously non-intuitive. This is the best guide I have found explaining them in a practical way: https://danceswithcode.net/engineeringnotes/quaternions/quat...

I used that guide to write quaternion functions for one of my projects. It is three times faster than the (also gimbal safe) trigonometric method I used previously. The quaterion functions can be found at the top of: https://github.com/kevinloch/bsrender/blob/main/src/process-.... The rotation quaternion is constructed at the bottom of https://github.com/kevinloch/bsrender/blob/main/src/init-sta.... The vector quaternion is constructed by simply copying the Euclidian x,y,z into i,j,k while setting r=0, and the output x,y,z is copied from i,j,k after rotation.

Beware my program uses a non-standard coordinate system where +y is to the left, being derived from equatorial coordinates used in astronomy where the x->y angle (Right Ascension) increases to the East. Removing the y-axis inversion/reversion steps in the quaternion functions should make them work with conventional coordinates.

The speed advantage of quaternions depends on the use case. If the points being rotated are natively Euclidian and you are performing the same rotation on a billion points then it's a clear winner as the expensive trig functions are only done once while the actual rotation steps are all + and *.

> Central banks were created because without them, finance was subject to wild, terrifying, ruinous boom/bust cycles.

Let's see how that is working out:

  Federal Reserve created in 1913
  Roaring 1920's -> 1929 Crash/Great Depression
  1960's Nifty Fifty -> 1973-1974 Crash/recession
  1980's bubble -> 1987 Crash and early 1990's recession
  Dot Com bubble -> 2000-2003 Crash/recession
  Housing Bubble -> 2008 Crash/GFC
  Everything Bubble -> ???

At least since the 1987 crash, artificially low interest rates from Central Banks and more recently outright money printing/QE enhanced or outright created the bubbles and busts. Even when viewed in the most favorable light their supposed moderating function seems to be horribly broken.

I think my first Linux distro was actually Yggdrasil, but right after that I tried Slackware and found it was much more complete and easy to use. You could also order a 4 CD box from Walnut Creek with tons of packages.

I kept subscriptions from Walnut Creek to both FreeBSD and Slackware for about 10 years. They would automatically send me new versions as soon as they were released.

Aside from oversubscription only a fraction of any customer's traffic will traverse the IX. The ratio will depend on who Starlink is peering with on the SIX (not necessarily everyone) and the traffic flows to/from those ASN's.

That said there are some very significant content peers present on the SIX: Akamai, Amazon, Apple, Edgecast, Facebook, Google, Microsoft, Valve, among others. Hurricane Electric is also there and has an open peering policy despite being a very large ISP with a significant percentage of Internet routes and traffic.

Two of those are on the normal vlan, and two are on the jumbo frames vlan. Both vlans are available on the same physical ports.

Confusingly they list each of those as 200G capacity, not sure if that's a typo or it really is 2x 2x100G.

https://peeringdb.com/net/18747

The last time I got a tour of the SIX, there were switches on two different floors in the Westin building. This is more for capacity than redundancy. The original location is literally a janitor's closet in a hallway and it's so tight that exhaust fans are built into the door. The second location was in proper four-post racks in a small room. It is possible they have ports on both switches for redundancy but more likely both are on the newer location. The SIX is also built into other buildings and they could connect to more than one, but there is typically only 200G backhaul to the other sites. https://www.seattleix.net/topology

2x100G to an IX are usually connected as separate ports, each with their own assigned IP ont he IX subnet. BGP multipath can enable load balancing across both ports. Otherwise you might have some peers configured on one port and others on the second. These days I like to have all peers on both ports and use BGP multipath.

If both ports are connected to a single switch on the IX side and the same router on the customer side then LACP can be used to combine them into a single 200G port with one IP. This is a less common configuration unless you are doing more than two ports (4x100G as 2x 2x100G lags for example).

There is another consideration: what happens if there is an icmp or arp flood on the IX? It's not supposed to happen but sometimes it does, even on the most major and well-run exchanges. In that case you might want to have all of your IX ports on one of your routers, keeping the other one "clean", just in case your control plane policing doesn't mitigate it.

Different networks place different priority on IX ports. In most cases it's ok if it's down for a short time (traffic will just shift to paid transit) so redundancy is not essential. In other cases it may be too much traffic to reroute so you care more about IX reliability and redundancy.

The intent of the standard /48 end user size was to prevent residential ISP's from being stingy and only assigning one IP. They wanted homes to have as many publicly routable subnets as the would ever need or want.

This was later revised to "/56 by default, /48 if you ask with no justification needed"

The IETF IPv6 allocation scheme was crazy from the start. The standard subnet size for autoconfiguration purposes is /64 = 18 Billion Trillion addresses. Of course reality is that autoconfiguration is only marginally useful and lots of things like servers and infrastructure links are statically assigned or assigned through dhcpv6. Most of the time I assign /112's to server subnets to limit the risk of IPv6 neighbor discovery attacks.

The standard /48 assignment size from ISP's to end-users was targeted mainly at stingy residential ISP's that were only assigning one IP per customer. They wanted any customer to have as many publicly routable subnets as they would ever need or want, but 65k is a lot of subnets. This was later updated to a default of /56 (256 subnets) but you could still get at /48 just for asking.

It got even weirder on RIR to ISP portable allocations. One of the original schemes would have RIR's allocating a "TLA" /16 (!) to only a few mega ISP's. Most ISP's/hosts would have to get their "NLA" address blocks from and be subservient to the 800 pound gorillas in the industry. https://www.rfc-editor.org/rfc/rfc2450.txt, https://www.rfc-editor.org/rfc/rfc2374

This was loosened somewhat in 2000 with RFC2928 which designated a "Sub-TLA" /29 as the initial ISP size. This would open it up to many more potential registrants, at least in theory. https://www.rfc-editor.org/rfc/rfc2928.html

The TLA/Sub-TLA/NLA system was abandoned in 2003 with RFC3587 after panic set in that nobody was deploying IPv6. https://www.rfc-editor.org/rfc/rfc3587.txt. ARIN had only made 30 Sub-TLA assignments by the end of 2002.

While RFC3587 wisely punted allocation policy to the RIR communities, the RIR's still had very restrictive policies inherited from RFC2450. Only around 2004 did they loosen to the point that ordinary networks could start requesting addresses. Google for example got their first IPv6 allocation in 2005. The problem is by then few networks were interested or just assumed they wouldn't qualify. When I got my first /32 in late 2004 there were less than 1000 routes in the global IPv6 table! Today there are ~135,000.

These more permissive rules only applied to ISP's/Hosts. End user orgs of any size were not allowed to start requesting portable /48's directly from RIR's until 2006 after much debate in RIR communities and vocal objections from IETF members and certain large ISP's.

Today router silicon and RIR policies have converged to a reasonably functional state. Too bad it took 20 years to get here or IPv6 might actually be on it's way to replacing IPV4. Instead that is still about 20 years away.

Here's the field notice: https://www.cisco.com/c/en/us/support/docs/field-notices/637...

and more general discussion: https://www.cisco.com/c/en/us/support/web/memory-component.h...

The field notice only applies to cards but the power supplies were definitely prone to permanent failure on power on, possibly from a different type of failure. I replaced more dead power supplies (that had died on power up/cycle) than line cards over the years that I used them.

Excessively large buffers confuses TCP windowing. On network devices like switches and routers buffers are only actually needed for two things: internal switching/routing latency (which is usually constant and very small) and serialization onto output interfaces (which varies by input/output port speed mismatch and/or number of inputs multiplexed to one output). Handling network "burstiness" should be left up to the endpoint TCP stack or applications in the case of UDP. Ethernet flow control should be disabled unless you find it actually helps (unlikely).

On servers buffers have more work to do since the CPU may be busy with many other tasks. It is rare that I have had to adjust the default buffer sizes but keep in mind server buffers too large can increase jitter as well as confuse TCP windowing (depending on when ACK's are sent). Some applications may prefer that packets be dropped instead of queued for excessively long times.

The most important thing is to ensure that selective ACK's and window scaling TCP options are enabled. They are enabled by default in modern operating systems but you might be surprised how often they are disabled by clueless sysadmins. A common cause of this is/was buggy TCP offloading drivers where the apparent "solution" was to disable ALL tcp options instead of just TCP offload. Window scaling in particular is essential with modern port speeds.

All it takes is two or three manufacturers to agree on an interoperable standard and consumers will force the rest on board.

NTSC has a number of artifacts but this simulation added RF decoding artifacts as well.

The RF artifacts completely overwhelm the NTSC artifacts. It looks like a fairly weak RF signal plus other RF noise/harmonics in band.

There is a known hardware bug affecting every PSU and cards in the 6500/7600 series. It manifests as a significant chance of permanent failure on power-up after being on for several years. As long as the chassis stays powered everything is fine. If you reboot or power cycle you may end up with some random dead cards or power supplies.

The use of the "enterprise" 6509 as a backbone ISP router was the worst kept secret in the industry in the 2003-2007 timeframe. During that time you would see about about 60% of the routers in a carrier hotel were 6500/7600's. Most of the rest were Juniper MX or M with very few Cisco 12k, ASR, or CRS. The 12k used an inefficient fixed cell size architecture and focused on ATM line cards and the CRS1 was far too expensive for most operators. The Ethernet-based 6000/6500 series was originally developed by the enterprise vertical at Cisco as an L2 product, but it gradually evolved to full route scale L3 features at a much lower price point than the "real" ISP routers. This price advantage was especially dramatic when 10GE interfaces for the platform came out in 2003. Cisco replaced the 12k with the more popluar Ethernet focused ASR series but the very low cost of the 6500 kept them in use much longer than they should have been.

While dirt cheap due being officially marketed at enterprises and a robust greymarket for parts, the 6509 was far from an ideal platform for ISP's. It generally performed well but there were a number of quirks from an internal architecture that gradually evolved from L2 only->full scale L3. RP cpu/ram was woefully under powered and control plane policing was marginal at best. Any significant packet flow to the RP instead of being forwarded by the ASIC hardware would instantly cripple the router and cause it to drop all BGP/OSPF/IS-IS sessions. In addition to broken control plane policing there were more scenarios where packets could be punted to the RP unexpectedly compared to other platforms. For example if any of the TCAM partitions filled up then ASIC forwarding was immediately disabled and ALL packets were sent to the RP! You also had to watch traffic levels when round-tripping on adjacent 10GE ports on the most popular cards to ensure it didn't exceed about 6 gbps or those ports would start dropping packets. Real ISP routers can often do full line rate in+out on all ports.

The monolithic IOS for the platform was notoriously buggy, partly due to the architecture and partly due to an enterprise feature set that most ISP's didn't even need. It was wise to avoid any version where the release notes claim to have just fixed a catastrophic bug (you wanted to see only boring fixes to cosmetic bugs or features you would never use) and to search the c-nsp mailing list for other's experiences with the version. Otherwise you were playing "IOS Roulette". Because of this it was common to run a known stable version much longer than normal, running the same version for 5+ years in some cases. After the fail-on-power-up bug became known most left them running without even a reboot until they could be replaced.

In more recent years Arista has made a similar play by evolving their switches from originally focused on minimum L2 latency to full route scale L3, and more recently adding full MPLS support at a lower price point than the equivalent C/J products.

I didn't realize Atari made a 68030 machine. It's too bad they didn't pivot to high end engineering/academic workstations to compete with Sun/SGI. They definitely had the engineering talent.

This is one problem (of many) that will have to be solved before we can have "generation ships" for interstellar travel.