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

First, I am extremely impressed by the demo. It looks truly groundbreaking.

Could you elaborate on the types of tasks and data sources used to train Ace, and how these contribute to its performance on desktop automation?

Ace is said to outperform other models on your suite of computer use tasks. Can you provide more details on these benchmarks and how Ace compares to existing automation tools?


The main problem with alternative browsers on iOS is JIT compilation. It breaks codesigning and thus is only allowed by Apple’s own code. If random third party apps could JIT their code, it would defeat many security measures


There are several inaccuracies.

Everything after “Darwin Kernel Version 21.2.0” is XNU, not iBoot. This is when macOS starts according to the diagram. You don’t see logs from iBoot.

I have no idea what this means:

> The end of the kernel-only phase, which is entirely iBoot, comes almost 20 seconds after the start.


> You don’t see logs from iBoot.

IIRC there's a serial console according to Asahi Linux people. Not sure if iBoot logs anything to it.


It does not. Apparently these days iBoot only logs to a proprietary USB debug protocol we haven't figured out yet.


> comes almost 20 seconds after the start.

Wait... an M1 Mac takes 20 seconds to boot?? A middle of the range windows machine in 1996 booted quicker than that...


It does not, not fresh and without boot time actions to take. Certainly not the laptops.

The Mac Mini used to have a larger delay dependent on the monitor attached, due to monitor detection times; about 7 seconds to the XNU kernel being launched, or 13 without a monitor (I guess it waits for monitor detection to time out), but now that Apple removed boot-time display support on those I imagine it no longer matters. The laptops have a much shorter time since they only have to deal with a well controlled internal display.

So it's possible that an M1 Mac Mini with no monitor attached pre macOS 12.1 took 20 seconds to boot to a login screen, but that's the worst case configuration.

(Yes, removing the bootloader framebuffer is stupid; I have a bug filed with them about this, but haven't gotten a response yet)


Just to follow up, it's about 16 seconds on a MacBook Air. 7 seconds of that are iBoot, and 9 are macOS. If you turn off the startup chime sound (which is a checkbox in system settings), that cuts out 2 seconds of iBoot time and makes it 14 seconds total.

For comparison, a ThinkPad X230 running Arch takes 7 seconds to GRUB (which I skipped through as fast as possible), FDE unlock prompt at the 12 sec mark, and after typing in my password it takes a further 13 seconds to get to a graphical login prompt (so 25 seconds total time).

Honestly, adjusting for the fact that Linux does fewer things before the FDE unlock than macOS, and more things after it and before the login prompt (I've got a few extra daemons and thing installed), I'd say they're quite comparable. The MacBook is a bit better (2s faster firmware without the chime).

Of course, half the point of these machines is they can run weeks while in sleep mode (or even while powered on as long as the CPU is idle and the display is off) and they have practically instant wake. So boot time isn't really relevant, since you rarely have to shut down.


> If you turn off the startup chime sound (which is a checkbox in system settings), that cuts out 2 seconds of iBoot time and makes it 14 seconds total.

Lol, wait, so the startup chime blocks the rest of the boot process?! I would have expected the system to be working on booting while the chime was playing.

Now I'm not sure whether I should keep the chime turned on. I like the chime, but I'm not sure I want to pay two extra seconds for it. :)


I think it's mostly that by the time the system is ready to play the chime, it takes less than two seconds to do whatever is left before transferring control to iBoot2, and of course you can't leave audio playing as you call a new piece of code... so even if the playback happens in the background, it would still have to wait for it to finish.


That doesn't seem right - though I must say macs have always felt to me as if the boot->user desktop takes way longer than other OS'es.

I guess the M1 counterpoint is the very, very fast sleep->wake speed.


> I have no idea what this means:

Userland is instantiated.


It’s already been confirmed that kernel extensions will work on the ARM macs. From there it seems straightforward to get a basic Linux loader going.


The biggest obstacle for those is a ton of work for drivers. Arm macs also don't use UEFI but iBoot + DeviceTree, however we provide a bridge bootloader as a part of checkra1n (pongoOS) that can be loaded after iBoot, and it boots Linux on an iPhone just fine. :-)


This is straight up misogynistic and is a great example of why women are driven away from our industry, because of language like this.


I don't think so. If you swap gender roles in the text its not demeaning and is still a cheeky commentary on married life. Mentioning a woman or their relationship to a man (in this case) doesn't automatically make it offensive.


While it is a very unusual metaphor, I don't see how it is misogyny or derogatory against women. This is wildly off-topic but I'd be interested to hear your thoughts.


It’s archaic. The analogy isn’t well served by using women and sex as an example, and I don’t really see why someone needs to hear about touching women in ways they don’t like when all they’re talking about is a shell configuration.

This probably would have gone down well back in the 60s, but we’ve hopefully since moved on from comparing women to objects, and comparing how we treat women to how we treat inanimate things.

Personally, I downvoted because the author’s attitude to women has absolutely nothing to do with discussing good alternatives to laptops.


Because men and women still marry and still chose each other as partners?

And the more men and women wait for that moment to chose the right person, the more the probability of making the right choice increases.

As long as I support women rights, I don't see what's wrong if an eterosexual man talks about choosing the right woman for him.

Should men not chose carefully their partners?


Yes it is a strange metaphor but language like “I might stumble a bit and touch her in ways she doesn't like” is rapey and comparing women to config files is just weird. The whole comment feels like it is objectifying women


You're right, you have a good point there.


> “I might stumble a bit and touch her in ways she doesn't like, but overall we get the job done and nothing is broken afterwards.”


Should have (2017) in the title.


Done. Thanks!


Ctrl-R and Ctrl-S please. Using the arrow keys for searching through history quickly (i.e. without leaving the home row) sucks.


It's not the same as ctrl-R/ctrl-S, but you can use ctrl-P/ctrl-N to scroll history like with the arrows without leaving the home row.


I've been quiet happy with https://github.com/junegunn/fzf/wiki/Examples-(fish) as a ctrl-r replacement for fish. I would love this included natively in fish though so I won't have to manage remote shell configurations.


+1. If some developer reads this, Ctrl+R is the only missing thing I can't imitate from bash.


I know this might not be what you'd want, but I'm doing this with fzf[0]. I have something like this as an alias:

  eval (cat ~/.local/share/fish/fish_history | grep 'cmd:' | cut -c8- | fzf --tac)
and then I simply bound it with `\cr`. It doesn't exactly replace Ctrl-R functionality but it suits my need.

[0] https://github.com/junegunn/fzf


you dont really need Ctrl-R in fish. Just type the command you are searching for and hit the up arrow key. Same effect


Ctrl+R is more convenient if you are a touch typist. Using an arrow key forces you to take your right hand off from the home row.


You can bind and rebind most keys. Are those two not possible?


The "Randomize order of array" snippet isn't actually random. It would just confuse the sorting algorithm.


It is end to end encrypted.


Sweet, now I don't have to keep Chrome around for Hangouts on OS X.


Are you being sarcastic?

This is the same, rudimentary "interface" that has always worked in all the browsers. :/


I used to use the Hangouts Chrome app but I will be using this now instead.


You know that this interface was available in GMail and G+ since Hangouts first launched, minus the "pretty background", right?


i dont see an option for OSX hangouts. Where did you get it?



but you need chrome for this don't you?


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

Search: