moduspwnens14

Definitely one of Claude's load-bearing terms.

Cheating (at least when I was school age) was fairly rare and not terribly difficult to detect. My concern is that both of those might be false with LLMs, and that'd make the circumstances different.

I agree. That's what I expect.

My optimistic hope is that for the more basic skills, teachers can adjust grading so that more easily-cheated homework provides less credit, and in-person work (such as a pop quiz) is weighed more heavily. Then, you're effectively setting yourself a time bomb by using LLMs on homework to avoid learning the material.

For higher-level skills, I think using LLMs will probably just become another skillset and part of the toolbox, just like the Internet was for my generation. But I guess we'll see.

That seems to be a common theme in the responses to me here.

The teachers set the course material and grading standards at least partially on how well the students are performing. Maybe not for a given class or year, but certainly over time. Scholarships are competitive. Slots in higher level courses are competitive, and often (at least partially) based on grades.

Can you imagine that the coursework and education overall might, over time, look quite different if half or more of students are regularly using LLMs, without explicitly disclosing it?

My daughter is only 1 and a half years old now, but my concern is more that she'll be implicitly competing with classmates that are using tools like this, whether we allow her to use them or not.

Locking semantics? Consistent listing of large numbers of files?

I'm speculating but those are at least the two I can think of that aren't explicitly linked to speed equivalency of a basic filesystem.

I tried out YNAB, Rocket Money, and Quicken Simplifi.

YNAB was a bit too opinionated and "hands on" for my tastes. Rocket Money seemed to be geared toward the "we'll cancel subscriptions for you" use case and was otherwise not configurable enough.

Quicken Simplifi seems much closer as a spiritual successor to Mint. It's mostly hands-off, though you can set up configurable rules and budgets. And it worked with all of my accounts.

Lambda has provisioned capacity now. You can just tell it how many to keep warm and it'll keep that many warm (but still cold start additionally as necessary).

This is exactly how we see it at my company.

Likewise, Linux is also a confusing mess of different parts and nonsensical abstractions when you first approach it. It does take some time to understand how to use it, and in particular how to do effective troubleshooting when things aren't working the way you expect.

But I 100% agree--I think it's the new Linux. In 5-10 years, it'll be the "go to", if not sooner.

It's confusing, but Docker images (and image registries) are also an open standard that Docker implements [1].

A lot of the Kubernetes "cool kids" just run containerd instead of Docker. Docker itself also runs containerd, so when you're using Kubernetes with Docker, Kubernetes has to basically instruct Docker to set up the containers the same way it would if it were just talking to containerd directly. From a technical perspective, you're adding moving parts for no benefit.

If you use containerd in your cluster, you can then use Docker to build and push your images (from your own or a build machine), but pull and run them on your Kubernetes clusters without Docker.

[1] https://en.wikipedia.org/wiki/Open_Container_Initiative

Does it do U2F on an iOS device?

If you haven't learned Kubernetes yet, it's probably a good use case for that.

Then use any of the other ideas here, except deploy them through Kubernetes.

My apologies if that's how it came across. My intention was to support the parent comment's assertion by pointing to a live example supporting his claim.

Honestly we already discussed this when Marzipan was announced. I guess the news here is just the years they're targeting? Regardless, a lot of the comments here are worried about what the headline implies, which is much more sinister than "a fast and clean way to make an iOS-focused UI app also work on the Mac." And there are already live examples on macOS that actually work fairly well!

Yes, and we are already seeing it. The "Home" app on macOS right now is clearly reusing a lot of iOS UI elements. It works, although it's tough to imagine a more native Mac app wouldn't be a better UX.

I think there's probably a case to be made when the app you're building is "mobile first," so you (as the developer) inherently do not want a richer, more feature-filled UI on the desktop. In that case, there's value in having a single UI to maintain and for that UI to be familiar to the user in both places.

Sure--I've no doubt there's some ugly workaround process to get around it, but I felt compelled to offer more information because it is usually the case that any Mac App Store app can be distributed outside the App Store relatively easily, except those that use the Network Extension framework.

I wanted to be sure the dev here is backed up that he's not making this up--this is Apple's restriction and not his.

> A much easier alternative is to have a dev account, then you can just enable the entitlements in your provisioning profile for your dev devices (or personal devices). Most entitlements don’t require any approval for a dev profile.

Yes, this is how we test on our own Macs before publishing to the app store. Although iirc those signatures have expiration timestamps, so you'll be re-signing and redistributing on some tedious interval (something like 30-90 days).

I'm an iOS/Mac dev that's released a VPN app on both app stores.

The limiting factor is that the "Network Extension" framework is the way these apps work as VPNs, and currently Mac App Store distribution is the only supported method if you're using that framework (see #8) [1].

[1] https://forums.developer.apple.com/thread/67613

It can also be helpful if:

- your system is distributed

- you don't want to be keeping a decryption key secure and in-sync across many (and potentially less-trusted) nodes

- the JWT contains attributes useful to the system (e.g. role, user ID, etc.)

You'll probably still be keeping track of a public key of whatever's signing it (to verify authenticity), but that isn't a secret. And then you can still securely trust

I've been using U2F where possible for about a year, and I have a secondary Yubikey registered everywhere I have the primary registered.

I am going to be switching to a USB-C one soon, though, and it only now occurred to me that I haven't really been keeping a "list" of all the sites where I've got them registered. Right now, not a lot of sites support it so it won't be too tough to find them. But I should probably be keeping a list so I at least can be sure when I've definitely replaced registered the new Yubikey in all places the old one was registered.

That doesn't really address your question as to what happens when you lose your keys, but it's perhaps relevant that there are a few warts around replacing even keys you haven't lost.

The climate system has fewer moving parts than a typical climate control system, so if anything, it is removing failure cases. It is unique—there are videos on YouTube that describe how it works if you’re doubtful.

In practice, I rarely adjust the climate setting after setting it to the temperature / orientation I want, but I suppose everyone is different.

To me it feels a lot like when many used to claim they could never get an iPhone because they prefer a physical keyboard. But I suppose we’ll see how the industry responds over the next few years.

The car doesn't require touching the screen to operate it.

The nav / media controls do, but those can be voice operated, too. And a lot of the media controls work from the steering wheel knobs (play pause skip back etc.), also.

EDIT: And all Teslas can have their climate control turned on remotely by the app / API, and can be safely warmed up even in an enclosed space (since there are no fumes).

My prior car was new and I later decided that the added expense of a new car did not justify it. My plan was to get a few-years old "A to B" used car (like a Corolla or something) when it started needing work.

But I did change my mind and get a Model 3.

* Autopilot is quite nice. I'd compare the experience to driving a car with cruise control as compared to one that doesn't have it. It's not the end of the world, but if you have a car with cruise control, it's tough to imagine intentionally buying your next one without it barring financial difficulties.

* Not having to fill up at gas stations is nice. There's a little more planning involved for trips, but for normal day-to-day, it's waking up every day to a full tank.

* Upcoming software updates. The initial Model 3s didn't have summon or the dashcam feature, both of which have been added over the air, and more of which will be added sooner.

* I think the auto industry in general has become stagnant and "safe" in terms of innovation, and I want to support a disruptive entity that will force the others to re-think the ways they're doing business.

* It's got an API, which already has third party tools for an Apple Watch app, detailed analytics, etc.

* They're taking a risk with the interior of the car, with the lack of gauge cluster and spartan design. To me this looks like what happened when the software industry switched from "as many UI buttons and features as possible" in the '90s to the simplified, "overall user experience" focus we see in modern software. And I want to support that.

* There's some "feel-good" factor to damaging the environment less, and supporting the market that will allow for society to join in.

I agree with you in that I can't imagine spending $63k on a non-Tesla. The differences between a basic used car and a new Mercedes or something just don't justify it. But I do feel differently about the Tesla.

Thanks for posting. This is a serious issue that is difficult to discuss openly and your perspective (particularly the part about a poor woman from a bad neighborhood's changing expectations) is something I hadn't seen or thought of before, but absolutely makes sense.

Sometimes. Apple certainly pushed back against Uber when they were skirting the rules a few years ago.

I'm not sure if it supports U2F. If it does, I haven't used it. It just seems to prove that what you were conceptually describing can exist, and at a not-completely-unreasonable price point.

I have a Ledger Nano S that I use for cryptocurrency and it does basically this. It won't sign transactions unless you approve them from the device, and the little screen on the device shows the address(es) to which you're sending.

https://www.ledger.com/products/ledger-nano-s

It's $100, which is probably too much for your average user, but cheap enough that it's got to be feasible for a U2F kind of thing in a few years.

I guess even the addition of the screen, though, kind of necessitates using a cord so you can see that screen, which makes it less clean than my Yubikey Nano (which is far less obtrusive). But I think we're getting closer.

OK. I guess to me categorizing those things in the same bucket as EC2 or Salesforce is missing a pretty fundamental architectural difference and benefit. I'm not claiming "serverless" is an ideal term, but I haven't seen the case made for anything better.

> I've seen this called Function as a Service and honestly I think using that term instead of Serverless would go a long way to fixing this issue

But "Functions as a Service" doesn't cover what it is, though.

The following AWS services are "serverless" but would not be "function as a service:"

* S3

* API Gateway

* SQS

* SNS

* Cognito

* DynamoDB

* CloudWatch (logs and metrics)

* Step Functions

In all cases, you are not provisioning or managing servers. Scaling is linear and costs are linear based on how much you use them, and typically based on what's actually being used (bytes stored, requests made, etc.) and not per-node. Because they're all hugely multi-tenant, they also cost almost nothing to use at low scale.

"Functions as a service" covers serverless compute, but it doesn't cover the huge architectural difference (from the developer's perspective) between the services above and rolling your own (for example) S3.

OpenVPN traffic over TCP 443 will still be distinguishable as OpenVPN traffic, it's just a little harder.

Normal TLS handshakes over TCP typically look very similar, so if OpenVPN did those, it would be tough. But OpenVPN's TCP mode is basically just a TCP encapsulation of the UDP mode messages, and even with the new tls-crypt option enabled, the packets still contain unencrypted parts that could easily identify them as OpenVPN traffic.

As far as I can tell, if you're looking for your TCP port 443 traffic to look just like normal web traffic, you'll need to use a different protocol.

Apple has been requiring all apps on the App Store work on IPv6-only networks for two years now [1]. They require it work on a network with NAT64 and DNS64 set up.

Essentially your device gets only an IPv6 address and the router translates IPv4 addresses to IPv6 ones. Your DNS server does the same thing. The end result is that your device talks only native IPv6, but the router is translating back and forth as necessary for IPv4.

It's actually pretty easy to test if you have an extra Mac laying around. There's a hidden checkbox on the Network preferences pane that lets any Mac create a NAT64 / DNS64 WiFi network [2].

[1] https://developer.apple.com/support/ipv6/ [2] https://developer.apple.com/library/archive/documentation/Ne...

This can't be used directly for generating OTP tokens (see the other comments), but what would stop you with a normal key on the secure enclave is that you can require the enclave itself requires a higher level of authentication (facial scan match, fingerprint scan) to perform those key operations.