- linuxに関する基本的な知識があるソフトウェアエンジニアもしくはヘビーユーザで、Quest 3のlinuxをGUI環境で使いたい人
- apkのインストールとか説明しませんが、Quest 3に入れたやつは、アプリ一覧からカテゴリでUntrusted Sourcesみたいなのを選ぶと出てきます
- termuxの上にlinux distroを載せるのは、遅いのでやりません(下記ベンチマーク参照)。prefixed-rootだろうがシングルユーザだろうがmusl libcだろうが我々なら大丈夫だ!
- linuxアプリのインストールは特記事項ない限り省略します。勝手にpkg installとかして
Create a file named user userconf (or userconf.txt) containing the following: | |
pi:$6$c70VpvPsVNCG0YR5$l5vWWLsLko9Kj65gcQ8qvMkuOoRkEagI90qi3F/Y7rm8eNYZHW8CY6BOIKwMH7a3YYzZYL90zf304cAHLFaZE0 | |
Place userconf (or userconf.txt) plus an empty file named ssh (or ssh.txt) in the BOOT (FAT32) partition of the SD card. | |
Insert the SD card in the Raspberry Pi and it should boot with access to user 'pi' (password : raspberry) via SSH. |
I have been wondering for a long time why IRC networks have multiple servers. Wouldn't it be simpler just to use a single server?
One of the problems of having multiple servers is that netsplits can occur. Anybody who has been on IRC for a while will have witnessed one. Hundreds of people suddenly ripped out of the chat. This can also screw up channel and user modes, and 'some people' have been known to wait for netsplits in order to takeover channels or enter password protected channels.
So lets compare situation (A) a single IRC server everyone connects to with the current setup people use (B) multiple servers. Let's say you run an IRC network with u = 40,000 users and n = 20 server nodes that people connect to via round robin DNS (meaning that when people resolve the DNS it gives them a random server from the set of 20 to connect to). These are vaguely realistic numbers modelled after libera.chat.
So in (B) you have roughly u/n = 2000 clients connected
d = document; a = d.createElement('pre'); d.body.appendChild(a); a.style = 'position:fixed;resize:both;top:200px;height:200px;width:400px;overflow:auto;white-space:pre-wrap;background:#46486787;z-index:1'; q = (x) => d.querySelectorAll(x)[0]; m = q('.messagelist'); t = ''; o = new MutationObserver(_ => { tt = ((q('.messagerow')||{}).innerText||'').trim(); if (tt && t != tt) { a.innerText = `[${new Date().toLocaleString('ja-JP')}] ${tt}\n\n${a.innerText}`; t = tt; } }); o.observe(m, { childList: true }) |
- DMM.com(旧DMM.comラボ含む)
- DMM.comラボ16新卒エンジニア研修 - (2016/08/24)
- DMM.comの新卒技術研修がスタートしました! - (2019/04/25)
- GMOインターネット
- 「Web 基礎」という講義をしました - (2019/05/17)
- GMOペパボ
- 2013 年の新卒研修メニュー
- ペパボ新卒エンジニアの研修を開始している - (2013/05)
- 第二新卒研修をしていた - (2014/08)
I've been fiddling about with an idea lately, looking at how higher-kinded types can be represented in such a way that we can reason with them in Rust here and now, without having to wait a couple years for what would be a significant change to the language and compiler.
There have been multiple discussions on introducing higher-ranked polymorphism into Rust, using Haskell-style Higher-Kinded Types (HKTs) or Scala-looking Generalised Associated Types (GATs). The benefit of higher-ranked polymorphism is to allow higher-level, richer abstractions and pattern expression than just the rank-1 polymorphism we have today.
As an example, currently we can express this type:
This is the second article in a series of articles around Rusts new async/await
feature. The first article about interfaces can be found
here.
In this part of the series we want to a look at a mechanism which behaves very
different in Rust than in all other languages which feature async/await
support. This mechanism is Cancellation.