KDE Projectは10月14日に20周年を迎えた。これを記念して、さまざまな企画が行われているが、KDE開発者のHelio Castro氏は1998年にリリースされたKDE 1を再リリースしている(Helio Castro Personal Spaceの記事、 Jonathan Riddell's Diaryの記事、 Phoronixの記事、 The Next Webの記事)。

再リリースされたKDE 1はモダンなビルドシステムにポートされ、モダンなシステム上で動作する。KDE 1.1.2までのCVSがgitにインポートされており、KDE gitから利用できるようになっているとのこと。KDE 1 neon LTSもリリースされており、Dockerイメージも提供されている。

FreeBSDなどの祖先であり、初めてPC/AT互換機で動作したとされるBSD系UNIX「386BSD」のソースコードがGitHubで公開されている（ソフトアンテナブログ、Slashdot）。

Slashdotによると386BSDの最後のリリースは1994年で、最後の一般リリース版のバージョンは0.1だったのだが、公開されているリポジトリには「0.0」「0.1」「1.0」「2.0」といったブランチが作成されており、また8月5日には「Upgrade to 386BSD 2.0」なるコミットも行われている。

Googleはすべての言語をカバーすることを目指すフォントファミリー「Noto」を5年にわたって開発しており、フォントやツールをオープンソースで公開している(Google Developers Blogの記事、 Google Noto Fonts、 GitHub - Google Internationalization、 9to5Googleの記事、 The Next Webの記事)。

Notoは指定された文字を表示するフォントがない場合に表示される「豆腐」をなくすことを目指すもので、「No more tofu」が名前の由来だという。2014年にNotoのWebサイトが公開された際の対応言語は570言語で96フォントだったが、現在では110フォントに増加。Unicode標準のすべての記号を収録しており、800以上の言語に対応する11万以上の文字を収録しているとのこと。

各フォントには複数のスタイルやウェイトが用意されており、すべてのフォントを一括ダウンロードするほか、個別にダウンロードすることも可能だ。なお、日本語を含むCJKフォントはサンセリフ系のみでセリフ系はない。ライセンスはフォントがSIL Open Font Licenseで、ツールやスクリプトはApache License Version 2.0となっている。

当初は日常使われる言語で豆腐をなくすことを目指していたNotoだが、今後は希少言語の歴史や文化をデジタル化する際にも使われることになる。また、Unicode標準に新しい文字が追加された場合には、Notoにも追加されていくとのことだ。

IBMがJavaの年次イベント「JavaOne 2016」で、オープンソースのJava仮想マシン「OpenJ9」を発表した（Publickey、openj9.mybluemix.net）。

OpenJ9は同社が先にオープンソース化を進めていたランタイムライブラリ構築ライブラリ「OMR」をベースとしている。OMRはIBMが開発していたJava仮想マシン「J9」のコンポーネントをベースにしており（InfoQ）、OpenJ9はJ9をオープンソース化したものとも言える。今後IBMはOpenJ9をベースに独自機能を追加したものをJ9として提供する方針で、Java 9のリリースと同時に正式リリースを行うことを目指すようだ。

なお、OMRはJavaに限定せず、さまざまな仮想マシン/ランタイムライブラリを構築できるようになっており、昨年12月にはORMをベースとしたRuby向けランタイムを公開している（OSDN Magazine）。

人員不足に起因する脆弱性修正の遅れなどによってプロジェクトの終了が協議される事態になっていたApache OpenOfficeだが、当面は開発が継続されることになった模様（窓の杜、Apache OpenOfficeの公式ブログ）。

公式ブログによると、まずは現在公開されているバージョンのバグ修正版となるバージョン4.1.3がリリースされる予定で、続いてそれに続くマイナーアップデート版となるバージョン4.1.4がリリースされるとのこと。また、新機能を含む新バージョンのリリースについても行う予定だそうだ。

PC-BSDが「TrueOS」への取り組みを強化することを明らかにした。従来は「PC-BSD for Servers」を「TrueOS」と呼んでいたが、今後はデスクトップ版も「TureOS」という名称で提供されるようだ。すでにWebサイトも公開されている（gihyo.jp）。

TrueOSはFreeBSDのCURRENT版をベースにローリングリリースを行っていくのが特徴で、毎週パッケージやインストール用ISOイメージが更新されるという。また、デスクトップ版とサーバー版の2種類が提供されるようだ。ただし、まだいまのところベータ版というステータスの模様。

Ubuntuを開発するCanonicalが、KDEへの資金提供を行うことが発表された（dot.kde.org）。

KDEのスポンサーとしてはすでにGoogleやQt、SUSE、Blue Systemsといった企業が参加しているが、これにCanonicalも加わることになった形。

Ubuntuの標準GUIシェルはUnityだがQtやQMLを利用したアプリケーションも増えており、Ubuntu側にはそれらに関する知見を共有できるというメリットがあるという。

Apache OpenOfficeが、プロジェクトの終了を検討しているという（いくやの斬鉄日記、OpenOfficeの開発メーリングリストへの投稿）。

開発が停滞しており、バグや脆弱性に迅速に対応できていないことが理由。現在議論が進められており、まだ確定したわけではないようだ。なお、プロジェクトが終了したとしてもソースコードは従来通り公開されたままになるため、有志がバグや脆弱性対応を行う事は不可能では無い。

OpenOfficeの開発体制については、昨年にも脆弱性対応が迅速に行えていないことが話題になっていた。

Mozillaは新しいブランドアイデンティティーをオープンデザインにより決定する計画を6月に発表していたが、これに基づく7点のデザインコンセプトが17日に発表された(Mozilla Open Designブログの記事、 The Next Webの記事)。

デザインコンセプトは「The Good Fight」「For the Internet of People」「Choose Open」「With you form the start」「Mrvericks, united」という5つのカテゴリーに分けられており、それぞれ1つまたは2つのコンセプトが割り当てられている。デザインとしては「Mozilla」「MOZILLA」「M」といった文字をモチーフにしたもののほか、Mozillaのオープンネスを示す「開く」ボタンをモチーフにしたものもある。

各デザインの詳細については、ブログ記事の本文の下に配置されている画像をクリックすると表示される解説ページで確認できる。本文の上にもデザインが一覧表示されているが、ここにリンクは張られていない。

Mozillaでは2週間ほどにわたってフィードバックを受け付け、デザインコンセプトを3種にまで絞り込む。9月半ばには絞り込んだ3種を公表し、9月末までに最終決定する予定だという。

デザインコンセプトにフィードバックを送るには、ブログ記事にコメントすればいい。なお、Aboutページでも説明されているように、最終デザインをクラウドソーシングすることはなく、人気投票を行うつもりもないという。コンペが行われることもない。スラドの皆さんが気に入ったデザインはあるだろうか。

maia 曰く、

鳥貴族のある店舗で、「アルコール製剤(食品添加物)」を焼酎のサーバーにセットして酎ハイを151杯提供してしまった(お詫びとお知らせ: PDF、 朝日新聞デジタルの記事)。

通常の酎ハイより泡立ちが多く、客から「味がおかしい」との指摘もあったという。店では誤接続時点でサーバーの不具合と考えていたが、5日目にメンテナンスで原因が判明するまで誤った商品を提供していたとのこと。問題のアルコール製剤はサトウキビから作られたエタノールが主剤だが、泡立ちからすると、pH調整や機能の安定化に使用される副剤があったのだろう。

誤提供があったのは鳥貴族 南柏店で、7月19日～23日までの期間。同社では食品添加物アルコール製剤を手指消毒用に使用しているが、焼酎の容器と形状・サイズが似た抽出口付きの透明容器に入っており、梱包していた段ボール包材を外して使用していたため区別がつきにくかったという。さらに、食品添加物アルコール製剤の抽出口の口径がドリンクサーバーの接続口の口径に近かったため、強引に接続可能だったとのこと。南柏店ではマニュアルを誤認識し、厨房内に段ボール製の包材を置いてはならないと思っていたようだ。

鳥貴族では該当商品を該当期間に注文した客に返金対応を行う。レシートがない場合も、来店日時や商品名、来店人数などを確認の上で返金するとしている。また、他店での誤接続がないことは確認済みであり、一目で区別できる容器の食品添加物アルコール製剤への一斉入替を手配するなど、再発防止策をとったとのことだ。

headless 曰く、

Free Software Foundation（FSF）が30年間の歴史で初の年次報告書を公開している（FSFのブログ、Phoronix、年次報告書PDF、高解像度版）。

FSFは1985年10月に設立され、昨年10月に30周年を迎えた。この年次報告書は2015年会計年度（FY2015: 2014年10月1日～2015年9月30日）のもので、FSFの活動や成果、財務状況などが紹介されている。およそ120万ドルの収入は91%が寄付によるもので、その85%はFSFが実施するさまざまなプログラムに使われたとのこと。

あるAnonymous Coward 曰く、

オープンソースソフトウェアのファイルホスティングサービスを提供しているFossHubが攻撃され、公開されていたオープンソースソフトウェアの一部にマルウェアが組み込まれるというトラブルが発生した（ZDNet）。

マルウェア汚染が確認されたのはAudacityおよびClassic Shell。Audacityの説明によると、攻撃者はなんらかの手法でFossHub.com上のある1つのアカウントの情報を入手し、そのパスワードを使ってFossHubにログイン後、何らかの手法を使って権限昇格を行い、サーバー全体へのアクセス権限を得ていたとのこと。

FossHubはこれを受けてFossHub.comを停止させ、調査およびサーバー全体の初期化を行っているとのこと。また、攻撃者はFossHubが使用しているDNSプロバイダやCDNサービス、メールサービスなどにもアクセスを試みたが、すべて失敗していたという。

insiderman曰く、

Microsoftが開発しているJavaScriptエンジン「ChakraCore」が、LinuxやOS Xでも利用可能になったそうだ（CIO、Microsoft Edge Developerブログ）。ChakraCoreはWindows 10やEdgeブラウザで採用されており、昨年にオープンソース化すると 発表されていた。

また、同時にNode.jsのJavaScriptエンジンをChakraCoreに置き換えた「Node.js with ChakraCore（Node-ChakraCore）」もリリースされた。どちらもまだ実験的リリースという段階とのこと。

ChakraCoreのソースコードおよびNode-ChakraCoreのソースコードはどちらもGitHubで公開されており、問題点の報告なども受け付けている。

caret曰く、

先日ストーリーになった ポケモンGOのWindows 10版を求める署名活動はついに10万人の大台に乗ろうとしているが、ついに非公式のポケモンGOクライアント"PoGo-UWP"が7月31日にGitHubで公開された（redditのwindowsphoneサブレディットのスレッド、WinBeta、Windows Central）。

開発者は「ST-Apps」と名乗っており、ポケモンGOの非公式クライアントライブラリ「Pokemon-Go-Rocket-API」をベースとしているようだ。このAPIはBotなど、旺盛に開発が続いているポケモンGOのチートツールにも利用されている。

Microsoftストアには登録されておらず、開発者モードでサイドローディングインストールすることが前提となっている。また、新規アカウント作成時のチュートリアル（最初のポケモン選択）は非公式クライアントでサポートできないため、BlueStacksなどでAndroid公式クライアントを利用する必要がある。

実際の動作画面はWindows Centralがハンズオン動画を公開している。なお、NianticのポケモンGOサービス利用規約に抵触する可能性があるため、当然ながらこのアプリの利用は自己責任となる。

公式クライアントが今後Windows 10向けに登場するかは不明だが、Microsoft PortugalがWindows Phone向けポケモンGOの近日中のリリースを示唆するコメントをFacebookに投稿している。

insiderman 曰く、

DropboxがJPEG画像をロスレス圧縮するツール「Lepton」をオープンソース（Apache License 2.0）で公開した（OSDN Magazine）。

LeptonはJPEG形式画像ファイルを圧縮するツールで、圧縮後は「.lep」という拡張子の独自フォーマットファイルに変換される。.lep形式に変換することで、平均22％ファイルサイズを縮小できるという。また、.lep形式ファイルからJPEG形式に復元した場合、オリジナルのJPEG画像とバイト単位でまったく同じものが生成されるという。

技術的な詳細についてはDropboxのTech Blogで紹介されているが、8×8ピクセルのブロック単位で処理を行うというJPEGのエンコード方式に注目し、その端をうまく処理することで圧縮を行うという技術のようだ。

JPEGよりも圧縮率が高いとうたう画像フォーマットはいくつか提案されているが、普及しているJPEGを置き換えるには至っていない。そのため、こういったアプローチでストレージ容量の削減を狙うというのは良いアイデアだと感心した。