Comments URL: https://news.ycombinator.com/item?id=49071168

Points: 2

# Comments: 1

As a little art project, I recently made a version for MS-DOS and AdLib [2] that starts with a piano-like sound and gradually distorts the timbre every repetition by flipping a random bit in the AdLib’s registers.

I never made a recording of it because I was envisioning it as an “if you got to see it in person, cool” type of thing, but I should probably go back and do that

[1] https://youtu.be/7GoV2psW-OE

[2] http://constcast.org/vexations.html

> Backend Not Found

> Why am I seeing this?

> There are a few potential reasons:

> You haven't deployed an app yet.

> Your app's first Rollout may still be in progress.

> This is a custom domain, but we haven't finished setting it up yet.

> How can I deploy my first app?

> Refer to our App Hosting documentation to get started.

I work as an Android developer at a large retailer, on the app that the in-store employees use to see their schedules, view product details, get support, etc. Part of our engineering on-call rotation involves helping these in-store employees with any app issues they may encounter. There are always a few times every rotation where I know solving someone's problem would be way easier if I could just see their screen as if I were in-store with them.

However, many of these employees are non-technical and wouldn't want to go through the onboarding of TeamViewer or Zoom, are under time constraints in a busy store, or (understandably) just wouldn't know how to get set up.

As a side project over the past few weekends, I've been building an Android screen sharing tool called Zipshare (https://www.getzipshare.com, demo video: https://www.youtube.com/watch?v=Iuc3HBIuMZE) that aims to be absolutely as easy as possible to use for the person sharing their screen. All the sharer needs to do is receive an email (or eventually a text) on their Android device and click a link. They will be sent to the Play Store, and upon launching the app, will automatically be sent to their session. Users don't need to create an account or enter a meeting code - there's literally one screen in the app ("xyz@abc.com invited you to share your screen, would you like to?") In fact, I originally wanted to use Play Store Instant Apps to eliminate the installation step entirely, but you can't open a raw socket from an Instant App, which I currently depend on... [1]

You can try the live demo by entering your email address and waiting on the next page, while clicking the link you receive on an Android device. Allow the screen share and you'll see it appear in your browser on the first device. When this is more built out, support agents will be able to sign in to their account and click a button to generate a new link/send it out. I also want to integrate with platforms like ServiceNow, PagerDuty, and Zendesk to allow generating screen sharing sessions directly from tickets.

I focused on Android for this initial version because the wide variety of devices makes giving support more difficult than on iOS, and because I have way more experience with Android :)

Other features I want to include are automatic notification suppression while sharing (for privacy), an "instant connectivity check" that reports basic system state to the agent like cell/Wi-Fi signal strength and whether a VPN is enabled, and an annotation feature so that agents can draw attention to certain areas of the screen.

My goal with Zipshare was to do one thing and make the experience as streamlined as possible. For example, there's no voice or video calling because chances are the two parties will already be on some other kind of call.

Technical details:

* Screen sharing: WebRTC with signaling provided by a self-hosted LiveKit server instance

* Android side: Kotlin, Jetpack Compose, LiveKit SDK, Play Store Referrer API to route the session ID through to the app install, "classic" Android 3rd party libraries (OkHttp, Retrofit, KotlinX serialization, ...)

* Website and API: Node.js, Express, two Pug templates, one CSS file, 50ish lines of JS excluding LiveKit, SQLite DB with one table.

Design details:

* Icon: Fiverr

* Colors: ChatGPT

* Landing page copy: The best I could come up with

Please give it a try and let me know what you think! I am eager to test this on as many devices as possible, especially older or low-end devices. I built this because I wanted it, but would it be useful for you or your team? Any feature requests?

[1] https://issuetracker.google.com/issues/191070661, naturally "Won't Fix", definitely something to hack around in the future

(note: I was given the OK to repost this for a second chance)

Comments URL: https://news.ycombinator.com/item?id=42451447

Points: 12

# Comments: 2

OK, so this looks like it’s reading one card’s worth of code from either an actual card or tape. Based on how KNOW is used, the mystery LETTER looks like it’s classifying each word based on what type of token it is… then it goes into an interpreter loop with what’s basically a switch statement on the IDENT of each word (derived from its entry in KNOW). So I think each card could have 14 tokens of up to 6 chars each, some only one character (like a parenthesis) or some an entire literal?

A108 is the per-word outer loop and A105 is the per-char inner loop. A102 and A104 are the labels where the loop indices are updated and it jumps back to the beginning of the loop. As far as I can tell, MADIN and MADOUT are no-ops. I’m not sure what KGETIN is doing.

I believe the 343434343434k is meant to simulate some extra cells with a bunch of right parens so you could just end your program without wasting another card on closing everything?

Edit: I just read page 24 of the linked SLIP manual and what I’m calling tokens they’re calling SLIP cells.

I work as an Android developer at a large retailer, on the app that the in-store employees use to see their schedules, view product details, get support, etc. Part of our engineering on-call rotation involves helping these in-store employees with any app issues they may encounter. There are always a few times every rotation where I know solving someone's problem would be way easier if I could just see their screen as if I were in-store with them.

However, many of these employees are non-technical and wouldn't want to go through the onboarding of TeamViewer or Zoom, are under time constraints in a busy store, or (understandably) just wouldn't know how.

As a side project over the past few weekends, I've been building an Android screen sharing tool called Zipshare (https://www.getzipshare.com) that aims to be absolutely as easy as possible to use for the person sharing their screen. All the sharer needs to do is receive an email (or eventually a text) on their Android device and click a link. They will be sent to the Play Store, and upon launching the app, will automatically be sent to their session. There's no need to create an account or enter a meeting code - there's literally one screen in the app ("xyz@abc.com invited you to share your screen, would you like to?") In fact, I originally wanted to use Play Store Instant Apps to eliminate the installation step entirely, but you can't open a raw socket from an Instant App, which I currently depend on... [1]

My goal with Zipshare was to do one thing and make the experience as streamlined as possible. For example, there's no voice or video calling because chances are the two parties will already be on some other kind of call.

I focused on Android for this initial version because the wide variety of devices makes giving support more difficult than on iOS, and because I have way more experience with Android :)

You can try it by entering your email address and waiting on the next page while clicking the link you receive on an Android device. When this is more built out, support agents will be able to sign in to their account and click a button to generate a new link/send it out. I also want to integrate with platforms like ServiceNow, PagerDuty, and Zendesk to allow generating screen sharing sessions directly from tickets.

Other features I want to include are automatic notification suppression while sharing (for privacy), an "instant connectivity check" that reports basic system state to the agent like cell/Wi-Fi signal strength and whether a VPN is enabled, and an annotation feature so that agents can draw attention to certain areas of the screen.

Technical details:

* Screen sharing: WebRTC with signaling provided by a self-hosted LiveKit server instance

* Android side: Kotlin, Jetpack Compose, LiveKit SDK, Play Store Referrer API to route the session ID through to the app install, "classic" Android 3rd party libraries (OkHttp, Retrofit, KotlinX serialization, ...)

* Website and API: Node.js, Express, two Pug templates, one CSS file, 50ish lines of JS excluding LiveKit, SQLite DB with one table.

Design details:

* Icon: Fiverr

* Colors: ChatGPT

* Landing page copy: The best I could come up with

Please give it a try and let me know what you think! I am eager to test this on as many devices as possible, especially older or low-end devices. I built this because I wanted it, but would this be useful for you or your team? Any feature requests?

[1] https://issuetracker.google.com/issues/191070661, naturally "Won't Fix" - definitely something to hack around in the future

Comments URL: https://news.ycombinator.com/item?id=42228461

Points: 2

# Comments: 0

    http://example.com/viewPost.php?post=../../../whatever

Comments URL: https://news.ycombinator.com/item?id=35963396

Points: 1

# Comments: 0

Is this saying that if I had a removable disk mounted at /mnt/foo and issued “cd ..” in that directory, I’d remain in /mnt/foo instead of moving up to /mnt? When did this change to the current behavior?

Edit: Maybe some tech exec with enough money that the museum's expenses are a drop in the bucket could help?

I’ve only done it with the 6502 and Z80, but the 8086 shouldn’t be too much harder. There are plenty of resources available online for those two chips that you could adapt!

The arcade isn't dead yet - there's still plenty of enthusiasm for rhythm and fighting games, which I believe is actually growing. At least among my friend group, it's much more rewarding to face off in person than to be trashtalked by some anonymous gamer on an online console gaming service. Also, when the arcade closes, there's nothing better than just sitting around and chatting for a few hours. Arcades make a fantastic "third place" [4].

[1] http://freeplayrichardson.com/

[2] http://arcadeufo.com/ (disclaimer - owner of this place)

[3] https://www.round1usa.com/

[4] https://www.pps.org/article/roldenburg