Hacker Newsnew | past | comments | ask | show | jobs | submit | e12e's commentslogin

Sony used to be surprisingly good on this - but I'm uncertain what the current status actually is:

https://developer.sony.com/open-source/aosp-on-xperia-open-d...

> Note: New devices XQ-CT62 (1Ⅳ US variant) and XQ-CQ62 (5Ⅳ US variant) do not support bootloader unlock.

https://xdaforums.com/t/unlock-bootloader-and-root-guide-xpe...


Fish is probably a good idea for an interactive shell. Osh/ysh might be a good idea for scripting:

https://oils.pub/

I'm still using bash out of habit, though. My one nod to modern tooling is using fzf for shell history search...


I think looking at some of the documentation for oils (née oil sh) and ysh - as well as [looking at using] these two projects [in place of bash] - is also a good idea today:

https://oils.pub/


I suppose this version of Arc for sbcl is different from what hn runs on?:

https://github.com/pauek/arc-sbcl

And there's no version of Anarki that runs on sbcl?:

https://arclanguage.github.io/


It's different, yes. The HN implementation is called clarc. PG suggested we spell it "clerk" as a joke on the British pronunciation of the latter, but I chickened out.

I talked to one of the Anarki devs (or at least someone who uses it) about possibly open-sourcing a version of clarc which would run the original open-sourced version of HN, but it's a bit hard because the implementation would require some careful surgery to factor out the relevant parts.


There's hn specific parts to the clarc implementation of Arc? (As opposed to the hn version of the "news" application)?

Yes because we just add the things we need, at whatever layer it makes the most sense to add them.

This type of application stack that includes the language you're writing in and even, when convenient, its implementation, is really satisfying to work with. There is much less need for workarounds, arbitrary choices, and various indirections (e.g. what used to be called dependency injection, for example). The plumbing is simple and it allows us to keep the codebase much smaller than it would otherwise be. I spend basically zero time bitching about having to deal with software dependencies, making me realize how much of my former life as a programnmer was taken up with that.

I think of this as sort of the unikernel form of application dev and of course it's a fine fit for a Lisp, since "write the language you want to write your program in as you write your program in it" is the natural style there. The tradeoff is that there's a lot of vertical coupling between the layers. If you want to factor out one layer for general consumption, e.g. to open source the language implementation so other people can build cool things with it, there's a fair bit of work to do.

Also, since the language implementation exists to run a specific application, we don't bother supporting what we don't need for HN. That too comes back to bite you when you want to open source!

HN has had 15+ years of work since the original news application was open-sourced; that's a lot of things-we-added at-some-point. Most are at the application level but some ended up in Arc and some in the Arc implementation when it was convenient to put them there. This is especially handy when you have limited time to work on the code.


Replying while @dang is editing - so might be talking past current parent:

I suppose I shouldn't be surprised that Arc/clarc would be modified as news is modified (Arc sort of being built around news in the first place).

I just wouldn't expect there to be hn specific sauce in clarc that would make sense to excise if opening up clarc; AFAIK it's been stated that there's some secret sauce wrt fighting spam, detecting voting rings and so on...

Then again, thinking more about it, it sounds reasonable that some of that might land on the Arc/clarc side, not in news.

[Ed: I think that turned out quite well]


(sorry for editing on the fly - I can explain why I do that but I know it can be annoying when someone is trying to reply! and yes, all that sounds right.)

I'm like you, there is an edit button, so I use it. I have to make a choice and I choose all the people who will arrive in the future over the small number of people who might have read what I've already poorly written, people who can get over it if they want to, even using their edit button if they wish.

I would really like to see how you implemented DI at the language level. Even at high level document or README file somewhere.

I think Dang is saying that you don't need DI. DI is a way of having some generic code be able to call some specific code when needed. If your whole stack is specific you don't have that problem - instead of the DI call site, you just call the function! Much simpler.

Yes, exactly.

I'm also interested in hearing more about this!

In my own game scripting scheme, I use implicit argument passing, like a cancellation token to async calls, and a rendering context used for immediate mode esque rendering.


So can you open-source clarc anyway? Even if it's not general-purpose it's surely of interest.

As a sibling notes there's certainly some secret antispam stuff, but surely that's not spread throughout the codebase too?


Clearly this is mostly security theatre (see eg comment about proving that them printer can't print a printer that can print a gun).

On the other hand - it would be low hanging fruit to prevent off the shelf printers to print well known gun parts? Much like photocopiers and scanners and printers won't scan, copy or print known currency bills?


> prevent off the shelf printers to print well known gun parts?

> copy or print known currency bills

Currency explicitly embeds detectable patterns to make software detection easy - firearm 3D models don't have any such feature.


Still would like a straight html version for reading on a phone. One with resizable text and proper reflow.

This! Pdf is nice, but not on a slow device/connection.

> The panel on Thursday recommended the manufacturing and sales of two iPS cell-derived products on condition that the two developers conduct studies involving all treated patients and further verify the efficacy and safety of their respective products within seven years.

> Cuorips, a startup originating from the University of Osaka, developed cardiomyocyte sheets for treating ischemic cardiomyopathy, a serious heart disease. Sumitomo Pharma submitted an application involving cells for transplantation into the brains of patients with Parkinson's disease, which causes symptoms including tremors in the limbs.

> The two companies had applied to manufacture and market the products last year.


In my mind, "yolo ai" application (throwaway code on one hand, unrestrained assistants on the other) - is a little like better spreadsheets and smart documents were in the 90s; just run macros! Everywhere! No need for developers - just Word an macros!

Then came macro viri - and practically - everyone cut back hard on distributing code via Word and Excel (in favour of web apps and we got the dot.com bubble).


The main thing that held me back from using Asahi on my M2 MacBook air - was missing external display. If I read TFA correctly - that should now work with a custom kernel.

If that's true - I'd say MacBook air M2 is probably the new sweetspot - depending on how cheap you could get an M1.

My impression is that until now, MacBook air M1 was the sweetspot.


yep it should work on M2 Macbook Air.

> (...) and the only communication channel would be towards me (enforced with things like API key permissions).

> This should prevent any kind of leaks due to prompt injection, right ?

It might be harder than you think. Any conditional fetch of an URL or DNS query could reveal some information.


DNS Queries are fine, and also conditional URL fetches, as long as they are not arbitrary, should be okay too.

I don't mind the agent searching my GMail using keywords from some discord private messages for example, but I would mind if it did a web search because it could give anything to the search result URLs.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: