CaliforniaKarl

That’s a broad claim to make. I think it’s worth providing numbers to back up that claim, especially since rates of return can vary a lot: A 6% return one year vs. a 10% return another year makes a huge difference.

Needs a [2016]

The site was throwing a 500 Internal Server Error when I visited. Here's an Internet Archive snapshot: https://web.archive.org/web/20170704191048/https://attila.ki...

HN posts have limits on title length. In such cases, it’s not unusual to post the original title as a comment.

For more on resistance dimmers in theater, check out this video from Jonathan Bastow: https://youtu.be/lTHNYWw6yt0?si=ygt0HpSd_aPcm3tq

https://csrc.nist.gov/CSRC/media/Presentations/usages-of-pub... has some.

You can still reach out to them, and see what they say.

That's a bit of an apples-and-oranges comparison. Cloud services normally have different design goals.

HPC workloads are often focused on highly-parallel jobs, with high-speed and (especially) low-latency communications between nodes. Fun fact: In the NVIDIA DGX SuperPOD Reference Architecture, each DGX H100 system (which has eight H100 GPUs per system) has four Infiniband NDR OSFP ports dedicated to GPU traffic. IIRC, each OSFP port operates at 200 Gbps (two lanes of 100 Gbps), allowing each GPU to effectively have its own IB port for GPU-to-GPU traffic.

(NVIDIA's not the only group doing that, BTW: Stanford's Sherlock 4.0 HPC environment[2], in their GPU-heavy servers, also uses multiple NDR ports per system.)

Solutions like that are not something you'll typically find in your typical cloud provider.

Early cloud-based HPC-focused solutions centered on workload locality, not just within a particular zone but with a particular part of a zone, with things like AWS Placement Groups[3]. More-modern Ethernet-based providers will give you guides like [4], telling you how to supplement placement groups with directly-accessible high-bandwidth network adapters, and in particular support for RDMA [4] or RoCE (RDMA over Converged Ethernet), which aims to provide IB-like functionality over Ethernet.

IMO, the closest analog you'll find in the cloud, to environments like Frontier, is going to be IB-based cloud environments from Azure HPC ('general' cloud) [5] and specialty-cloud folks like Lambda Labs [6].

[1]: https://docs.nvidia.com/dgx-superpod/reference-architecture-...

[2]: https://news.sherlock.stanford.edu/publications/sherlock-4-0...

[3]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placemen...

[4]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html

[5]: https://azure.microsoft.com/en-us/solutions/high-performance...

[6]: https://lambdalabs.com/nvidia/dgx-systems

This is one of two SQLite DB metadata that I really like. I've used `user_version` in the exact same way: I increment it by one every time I change the schema of the database. It's a four-byte signed integer (stored in the DB header in big-endian format), so it supports a large number of possible schema changes.

Folks should also be aware of the `application_id`, another four-byte signed integer accessed via pragma. This is meant to be set once, at the time you create the database. It's a way to ensure that the SQLite DB you are accessing is something that your code created.

For example, I use a line of Python like this to convert some human-readable characters (like 'KARL') into an application ID:

  >>> import struct
  >>> struct.unpack('=i', struct.pack('cccc', b'K', b'A', b'R', b'L'))[0]
  1280459083

So, I'd run `PRAGMA application_id = 1280459083;` when I create the DB. And on first access afterward, I'd run `PRAGMA application_id;`, look at the first (and only) row of output, and check for the expected number.

Finally, one thing to note: Because they're part of the database file's header, they are not affected by transactions. So, if you're using `user_version` to track schema changes, a schema upgrade becomes a "stop the world" sort of activity, so you can ensure it took effect.

[dupe]

https://news.ycombinator.com/item?id=41341353

There are three passing points on the line, where trains can pass each other without interrupting opposite-direction traffic. From North to South, they are…

• Between 22nd Street & South San Francisco, with Bayshore accessible via the 'local' tracks only.

• Between Redwood City & Menlo Park.

• Between Sunnyvale & Santa Clara, with Lawrence accessible via the 'local' tracks only.

Today, the northernmost and southernmost passing points are used by the Limited or Baby Bullet services to overtake the Local services. The service being passed has the middle station (Bayshore or Lawrence) as a scheduled stop, and remains in the station until they observe either a clear signal, or until they observe the faster service passing.

The passing point between Redwood City & Menlo Park is mostly used when a service (any service) is running slow, to allow on-time services to overtake. This is especially important when the slow-running service is a Local.

Finally, there are crossovers placed frequently along the line, often every 2-3 stations. These are used most often when maintenance is being performed on one section of track, or if a train is disabled. They are not used during normal operations.

FWIW, they don't sound worse to me, just different.

The link is paywalled, and archive.is doesn't have a copy, so here's a site where you can read the article:

https://www.yahoo.com/news/man-suing-emory-university-hospit...

The mentioned South Bay locations are xAI's Palo Alto office, and an office in Santana Row. Both locations likely have connections to Caltrain.

I don't know where xAI's Palo Alto office is, but transit in the corporate Palo Alto office are generally good. If xAI is in the Stanford Research Park, you'll be taking a shuttle that runs only during commute times, and takes 15-30 minutes, depending on where exactly you get off.

Santana Row is more confusing. You'll travel either to Santa Clara or San Jose and take a bus. From Santa Clara, the bus is ~15 minutes. From San Jose, the bus is faster, but you've got a half- or one-mile walk.

Stanford University IT | Stanford, CA (near Palo Alto) | Full-time | Three positions | 2 HYBRID & 1 REMOTE

Stanford University IT (https://uit.stanford.edu) provides a large number of IT-related services to campus. From typically enterprise-y stuff (financials software, HR software, AD, O365, Google, Zoom, etc.), to networking (building/core switches, firewall, campus wifi, residential networking, circuits, VPN, DNS, IP mgmt.), to endpoints (desktop support, lab endpoint support, Jamf, mobile phones), to research (computing, storage, hosting, consulting), we provide a broad range of services to campus.

I have three positions to shout out here:

• The Information Security Office both acts as a policy-making body and a service provider. ISO are looking for a Cloud Security Engineer. This HYBRID or REMOTE position will engage with cloud users (including Faculty and Students with their own cloud presence), helping to keep their cloud installations secure. You'll handle security reviews, vulnerability reports, and incident response. You'll use tools like Wiz, Splunk, Qualys, CrowdStrike, and ProofPoint, plus a lot more. For more information, check out http://phxc1b.rfer.us/STANFORDF81RNh

• Stanford University Networking is hiring a LAN Engineer. Responsible for 178k network ports and 17k Wi-Fi access points, LAN-E handles new physical network designs (for new builds and renovations), and acts as 2nd-level support for questions coming from the Local Network Administrators that support their end-users. LAN-E deals with Cisco & Juniper (both for Wired and Wireless), Palo Alto firewalls, VXLAN/EVPN, and WDM. For more information, check out http://phxc1b.rfer.us/STANFORD8JBRNg

• Stanford University Networking is also hiring a CT Senior Network Engineer. Communication Technology is the group responsible for voice comms across both the University and the Hospitals. We are primarily a Cisco Unified Communications shop, but we deal also with Avaya. Besides VoIP and analog service, you'll work with Contact Center, call recording, E-911, and underlying technologies (SIP, BGP, etc.).

The two Networking positions are HYBRID positions. If you don't already live in the Bay Area, we provide a relocation incentive. Depending on where you live, we provide free transit passes. Unfortunately, if you don't commute, you will have to pay for parking for the days you're on-site (except in Menlo Park).

The ISO position can be HYBRID or REMOTE. If Remote, expect to travel to either campus or our Redwood City offices a few times a year.

All three positions require participation in a 24x7 on-call rotation. We get a 403(b) match, good healthcare, and 30+ days off per year (holidays + vacation). All Benefits are all publicly documented at https://cardinalatwork.stanford.edu/benefits-rewards.

If you have questions, feel free to reply here or email me (the info is in my profile)!

For discussion on the DigiCert issue that triggered this, have a look at the following HN discussions (which are still active!)

DigiCert's blog post…

DigiCert Revocation Incident (CNAME Domain Validation) (digicert.com) — https://news.ycombinator.com/item?id=41104504 — 136 points by vitaliyf 1 day ago

… and the Bugzilla entry where DigiCert reported this to Mozilla:

Digicert pauses mass certificate revocation due to legal action from customer (bugzilla.mozilla.org) — https://news.ycombinator.com/item?id=41114794 — 9 points by frakkingcylons 23 hours ago

I don't know when they introduced it, but I believe MacPorts will build the common variants of the more-used packages. So, if you install a package with the default variants, you'll get a binary download instead of building from source.

But indeed; fast SSDs, parallel compilation, and modern CPUs really help!

> Stuff like this is why some parties have been calling for increasingly-shorter cert validity. When a cert is valid for several years it allows companies to develop an increasingly complex workflow around deploying them, sometimes taking weeks and involving dozens of parties to roll them out. This is in turn used as an excuse by CAs to completely ignore the industry standards.

"several years"? The certs we are getting have one-year lifetimes. It used to be two years, but was reduced to one year some time ago (I don't remember exactly when).

Also, I don't think the problem is cert lifetimes, I think the problem is having so many certs expiring all at the same time. A lot of IT folks are coming off the major pain of the CrowdStrike crash. This is similar: You suddenly have a very large number of certificates that are going to stop working in less than 24 hours, and you have to respond.

Sure, you could say "Well, companies should be resourced to be able to handle that at any point." Except that's not the reality right now.

Having a restraining order served on them is going to slow things down a bit.

I've been using MacPorts for as long as I've wanted a macOS package manager, and it's been working very well for me.

Area codes are not US-specific, they’re North America-specific. Some area codes are for areas outside of the United States, and may be charged at International rates.

There are enough people in the world that some can examine how this happened while others simultaneously examine why this happened.

The kernel update in question was released as part of a RHEL point release (9.3 or 9.4, I forget which).

I’m not sure how much early warning RH gives to folks when a kernel change comes in via a point release. Looking at https://www.redhat.com/en/blog/upcoming-improvements-red-hat..., it seems like it’s changing for 9.5. I hope CrowdStrike will be able to start testing against those beta kernels.

BPF-based CrowdStrike is relatively recent, partially because, from the Enterprise Linux perspective, kernel support is relatively recent.

For example, BPF-based CrowdStrike works on Enterprise Linux 9 and Debian 12. I don't know if the necessary support was in EL 8 or Debian 11.

Lots of systems (not all) are able to reboot, and have CrowdStrike download the fix before the bad code is able to crash things. But otherwise, yes, you have to go to systems manually.

Yes. CrowdStrike for Linux has had bugs in the past, though. This time the Windows version is affected.

They did, around four hours ago.

Our experience so far has been:

• Servers, you have to apply the workaround by hand.

• Desktops, if you reboot and get online, CrowdStrike often picks up the fix before it crashes. You might need a few reboots, but that has worked for a substantial portion of systems. Otherwise, it’ll need a workaround applied by hand.

Yes, from experience, I can say that CS does offer real protection.

> Even though the 14-50R outlet is technically a 50A outlet, when used as a kitchen range plug, they are often wired on a 40A circuit. This is permitted by the Canadian Electrical Code rule 26-744 5).

I wonder if the US National Electric Code allows this.

Should have a (2017)

There were a number of techniques used to block access to information:

For websites under the .cat top-level domain, the .cat registrar got takedown notices. The only workaround for this was to publish elsewhere.

For other websites, blocking access required ISP intervention:

• Two ISPs (Euskaltel and Vodafone) pushed changes to their DNS servers—the ones that subscribers use—modifying entries for web sites that were being blocked. This would be detectable by clients doing DNSSEC verification (assuming the domains used DNSSEC, which hopefully they did!). It could be worked around by using a different DNS service (like Google's), or by running your own recursive resolver, or by using a VPN.

• Movistar was doing Layer-7 traffic inspection: For HTTP access, the IP address and HTTP Host: headers were examined. For HTTPS access, the TLS SNI (Server Name Indication) message was examined. The workaround was to use a hostname that the server would respond to, but which wasn't filtered: For example, web.ref1oct.eu instead of www.ref1oct.eu. The other workaround would be to use a VPN.

The lack mode of blocking was the most interesting. I've heard of the risks of SNI-based filtering, but hadn't seen it in the wild yet!