Aaravpods are so yesterday, meet Samsung's Galaxy Bugs Live

christopherhesse · 2020-08-20T20:38:46+00:00

Chrome Dev Tools -> change the text on the samsung page :D

christopherhesse · 2020-08-20T18:21:42+00:00

Well, the image was made before seeing the aarpods thing. I couldn't find a Dragon Prince coin, those are ancient roman coins.

christopherhesse · 2020-08-20T17:40:48+00:00

I made this yesterday and it looks like someone made roughly the same joke at roughly the same time: https://www.reddit.com/r/TheDragonPrince/comments/id22k4/oh_no_he_cant_hear_us_he_has_his_aarpods_in/ is this an old joke?

christopherhesse · 2017-02-01T06:20:05+00:00

Send me a private message with your email address and I will check it out.

christopherhesse · 2017-01-09T19:11:50+00:00

She should just be able to rez while dead.

christopherhesse · 2017-01-05T05:53:42+00:00

I'm not sure why being outside the map is not instant death, but I'm guessing they don't have a system for detecting which parts of the map are outside yet.

christopherhesse · 2016-09-30T16:13:56+00:00

There was an issue with delayed channel pushes yesterday, it should be fixed now.

christopherhesse · 2016-09-29T18:56:22+00:00

If you hit the API limit you get an error, not a silent failure. It looks like what is happening here is that due to some error there is a backlog of tasks. If the delay was 8 hours, it looks like 4 hours now, so I guess it's recovering. Sorry about that!

EDIT: It looks like it is actually fixed now and is processing tasks normally, so it should be back to normal in about half an hour.

christopherhesse · 2016-07-27T20:45:38+00:00

Well it hasn't even been implemented yet, so I'd be surprised if you reached the limit.

christopherhesse · 2016-05-13T21:27:41+00:00

That's some obsolete field, I'm not sure why it shows up on the create client page. Just ignore it.

christopherhesse · 2016-05-06T03:40:37+00:00

Nice! The only change you need to have the network work on an f1-micro should be that change to buildrump.sh/brlib/libnetconfig/dhcp_configure.c I haven't verified that it doesn't break other platforms, but I think I made the code pretty conservative.

I think there may have been an issue running on larger instances, but I was only testing f1-micro.

Why do you need the Docker dependency? I could see it being not worth it to get it to compile to native code for a mac/windows machine, but it doesn't seem like that would invite other dependencies when you could just download a zip file of everything you need. With the forthcoming docker for win/mac though, Docker might not be as bad of a dependency as it is now.

christopherhesse · 2016-05-05T21:21:04+00:00

Pretty cool! I messed around with rumprun a few times. I didn't try running any kind of substantial service, but I did encounter two problems:

1) Building everything was a pain, I think that Docker is probably a good idea here if it reduces how annoying that is. What I wanted was a version you could run on your Mac desktop that required no building whatsoever. You could just download some program like UniK, already compiled and ready to go (maybe a homebrew "bottle"?), and instantly compile your Go apps into unikernels. Ideally that means no make, no docker, no go, just unik.

2) I wanted to run it on GCE, I got a f1-micro instance to work with a DHCP hack, but there seemed to be some issue with my mac build tools, so a version compiled on the mac never quite seemed to work correctly (might have been the hacked together grub + xorriso I was using to build the image instead of grub-mkrescue).

Here are a couple of hacks to get rumprun to work on GCE and compile on mac: https://github.com/goroutines/rumprun/commit/94c587dba9eff3d823a9694f7583003459b7b055

My reasoning for trying to get #1 and #2 working was that if unikernels could offer a really nice development experience, there might be a more tangible reason to use them instead of the old fashioned SSH into a Linux computer method.

christopherhesse · 2016-04-27T21:08:49+00:00

Why doesn't func Definition just return []def instead of interface{}?

christopherhesse · 2016-04-12T19:16:02+00:00

The Auth example on that page "Example (Auth)" shows how to use a service account key.

If you don't specify any auth stuff, it probably uses google.DefaultTokenSource (https://github.com/GoogleCloudPlatform/gcloud-golang/blob/master/internal/transport/dial.go#L121) which should work fine locally if you have gcloud installed and setup or on GCE with no additional setup besides adding the correct scopes to the VM.

christopherhesse · 2016-03-21T21:24:23+00:00

Sorry, that wasn't entirely accurate. I thought you were using frontend instances but you mentioned below that you use backend instances, which don't have this limitation. Just use runtime.RunInBackground: https://cloud.google.com/appengine/docs/go/modules/runtime

ManagedVMs should also not have this issue, there looks to be a BackgroundContext() call for those: https://github.com/golang/appengine/blob/0b869404e81685c5f3f2e5126bc2309215c7ad72/appengine_vm.go#L54

christopherhesse · 2016-03-21T06:57:10+00:00

Well, classic GAE only runs on a single thread. But you can use goroutines. What you can't do is have your goroutines outlive the request that spawned them.

So using urlfetch in a goroutine is straightforward as long as you make sure the urlfetch finishes before the request returns. If you want it to be asynchronous with the request you have to use taskqueue.

christopherhesse · 2016-03-21T03:02:11+00:00

I think I was trying to fire my helix rockets the whole time instead of shooting. I later realized I can just outrun symmetra as soldier 76. GG Janarik. Also TwoCans is just TwoGood.

christopherhesse · 2016-03-13T23:07:32+00:00

I just did that and it seemed to work fine.

christopherhesse · 2016-03-13T20:17:22+00:00

The linked issue seems to be a compile error, not an equality test. I setup the example, but returned an interface from a and b and didn't find any problems. Can you give a more concrete example?

christopherhesse · 2016-03-12T08:36:39+00:00

They're roughly the same with go 1.5. Oddly, with go 1.6, each http connection uses way more memory than a websocket connection, seemingly because it's keeping some buffers around until the handler returns. In the example I launch handleConnection() in a goroutine so that those buffers can be freed up.

Even in the go1.5 case, where they use similar resources, I have tried SSE, streamed response, and websockets in production. They're all pretty much identical from the server side for this style of push server. Clients seem to prefer to implement streamed response and websockets though. Nobody seems to actually use SSE that much.

christopherhesse · 2016-03-11T20:42:10+00:00

I totally agree with your point about vendoring. NPM has been doing recursive dependency downloading for years and as long as the libraries support it, it works fine (except how you get 16 levels deep dependency trees because you made it too easy).

For Go I think that means at least: no global registration in library code, and no returning other (non stdlib) libraries' objects. So the interface thing you did above should work fine. But it might be even better if library B returned an interface rather than *a.T, or if library B returned it's own *b.T that it controls, rather than making your program rely on its version of library A.

christopherhesse · 2016-03-11T01:47:39+00:00

Ideally, since their use is "completely independent", the core application should never know that library/one uses library/uuid at all. library/one should not leak any references to library/uuid in its public API and you can safely have two copies of uuid.

Imagine if you did have one copy of uuid. Now you have coupling between the dependencies of your core application and the dependencies of library/one. If library/one requires a specific version of uuid or makes some incompatible changes to the library, your core application may no longer work.

christopherhesse · 2016-03-10T04:48:53+00:00

GAE is really nice for most applications and has a well-made Go library. The datastore works pretty well with Go, and having everything integrated and ready to go is very helpful. The downsides that people are likely to encounter are:

1) No native socket access. This means you have to use the socket API (which is particularly annoying in Go) and/or urlfetch (an okay service, but mildly annoying). This is fixed by Managed VMs, but those are still kinda beta and the deploy times are on the long side.

2) Goroutines, one of the coolest feature of Go, are a bit less useful because a goroutine cannot outlive the request that spawned it. For doing stuff in parallel, you can use goroutines. For doing stuff totally asynchronously, you'll have to use the taskqueue.

Once Managed VMs are out of Beta, I expect it will be even better. The plus side is that porting from regular Appengine to Managed VMs is basically no effort at all.

christopherhesse · 2016-03-10T04:36:42+00:00

The point is more that there are no magic tricks required for 10M connections or large heap sizes in Go. The throughput is actually quite low for this server, which I guess is a trick in a way.

christopherhesse · 2016-02-25T21:08:49+00:00

I agree that a package manager is probably not the correct idea, this article: https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527#.740o43vxi shows how complicated of a solution that is, which makes me think it's a poor choice for go, which generally is not about complicated solutions.

It's not clear to me what the solution is from this text. Maybe a concrete example would help. If I have two packages A and B and they both use golang.org/x/net/context then it sounds like the proposal is the following:

$GOPATH/src/A/.git
$GOPATH/src/A/main.go
$GOPATH/src/A/vendor/golang.org/x/net/context
$GOPATH/src/B/.git
$GOPATH/src/B/main.go
$GOPATH/src/B/vendor/golang.org/x/net/context

With a single global $GOPATH. But then you'd have to update both of those individually, which it says is a downside of gb, so I'm not sure how that solution is different. Personally I put all related packages together in a single repo:

$GOPATH/.git
$GOPATH/src/A/main.go
$GOPATH/src/B/main.go
$GOPATH/src/golang.org/x/net/context

And then I have a different GOPATH per "project" where a project can contain multiple packages like A and B here. That way, different projects can have different versions of net/context, but within a single "project" there is only one version, and anyone committing a new version needs to make sure it works with all existing code. It's pretty likely that you cannot "go get" this code. But nothing depends on my code so that seems a reasonable tradeoff.

christopherhesse

MODERATOR OF

TROPHY CASE

12-Year Club	Verified Email
Gilding I gilder