similar to: R for Chrome OS

On Thu, 28 Feb 2019 08:16:05 +0000, Greg KH <gregkh at linuxfoundation.org> wrote: Hi both, > > On Wed, Feb 27, 2019 at 04:36:39PM -0800, Daniel Verkamp wrote: > > Hello, > > > > In my testing of crosvm[1] with Linux 4.4.175, I am observing failures > > on a 'kevin' Chromebook (RK3399) device - the guest kernel does not > > even get to the

On Thu, 28 Feb 2019 08:16:05 +0000, Greg KH <gregkh at linuxfoundation.org> wrote: Hi both, > > On Wed, Feb 27, 2019 at 04:36:39PM -0800, Daniel Verkamp wrote: > > Hello, > > > > In my testing of crosvm[1] with Linux 4.4.175, I am observing failures > > on a 'kevin' Chromebook (RK3399) device - the guest kernel does not > > even get to the

I don't know about the configuration. I installed R using the standard protocol for Chromebook http://blog.sellorm.com/2018/12/20/installing-r-and-rstudio-on-a-chromebook/ the rest, it was done by the system itself... On Tue, Jul 14, 2020 at 1:30 PM Dirk Eddelbuettel <edd at debian.org> wrote: > > > There is something wrong with your system / setup I did not notice first: >

Hello, In my testing of crosvm[1] with Linux 4.4.175, I am observing failures on a 'kevin' Chromebook (RK3399) device - the guest kernel does not even get to the point of printing its first messages, and the host seems to be spinning at 100% CPU in KVM_RUN. I narrowed this down to the 4.4 stable backport of "arm64: KVM: Skip MMIO insn after emulation" - with this patch

Hello, In my testing of crosvm[1] with Linux 4.4.175, I am observing failures on a 'kevin' Chromebook (RK3399) device - the guest kernel does not even get to the point of printing its first messages, and the host seems to be spinning at 100% CPU in KVM_RUN. I narrowed this down to the 4.4 stable backport of "arm64: KVM: Skip MMIO insn after emulation" - with this patch

Hi, I am testing Google's recent ability to integrate Chromebooks into AD and it's failing when I try to join the device to the domain. When I run wireshark during the test I notice 2 TGS-REQs from the device that are answered with KRB5KDC_ERR_ETYPE_NOSUPP. The Chromebook is only passing AES256-cts-hmac-sha1-96 and AES128-cts-hmac-sha1-96 as enc types. I was getting the same result from

Hi folks, I've been playing with LLVM on a Chromebook (Ubuntu) and it seems to work quite well. Installing Ubuntu on the Chromebook was a breeze[1] and all tools/libs/headers required to check-out and build LLVM were accessible via apt-get. I had two problems to build it, but apart from those, it all ran smoother than I'd expected. I'll investigate the errors a bit deeper later on,

I've got a netbook, circe 2009. When I got it, not that I was wild about ubuntu, but there was specifically an ubuntu netbook remix. Well, it's a few years later - has anyone put CentOS (6, preferably) on a netbook, and were there any problems? mark

I ran both scripts last night and was able to get the Chromebook to join the domain this morning. Thanks, Achim! For posterity's sake, I should mention that I changed the user's password when I enabled AES on their Account tab, in ADUC. Thanks, Mike On Wed, Dec 27, 2017 at 9:52 AM, Achim Gottinger via samba < samba at lists.samba.org> wrote: > Hello Mike, > > Can be you

> A Toshiba CB35 Chromebook running Google's stock SeaBIOS reboots after > selecting a relocatable kernel from extlinux 6.03. > > This is a regression caused by commit 8f470e7b > movebits: Add syslinux_memmap_find() > > which factors syslinux_memmap_find() out of bios_boot_linux(). Prior to > the refactoring, prot_mode_size was passed as the length in the first

A Toshiba CB35 Chromebook running Google's stock SeaBIOS reboots after selecting a relocatable kernel from extlinux 6.03. This is a regression caused by commit 8f470e7b movebits: Add syslinux_memmap_find() which factors syslinux_memmap_find() out of bios_boot_linux(). Prior to the refactoring, prot_mode_size was passed as the length in the first call to syslinux_memmap_type(). After

Chrome OS will soon be adding the chrome.fileSystemProvider[1] API, which would enable the development of a Samba Chrome OS app when used in conjunction with the chrome.sockets.* API or the networking APIs provided by NaCl. Is anyone on this list interested in porting or integrating Samba with Chrome OS? If so, there are two routes we can take: a full JavaScript port, or porting an existing C++

On 20 November 2013 23:11, Mikael Lyngvig <mikael at lyngvig.org> wrote: > My XU is on build 141 and there hasn't been a single problem yet. No > reboots, no crashes, and as far as I have observed no core dropouts (after > I did the cpu-freq trick you sent me). Perhaps I have a stable board or > perhaps it is because of its revision (rev. 0.3)? > That's good to

Google Chrome Terms of Service(Google Chrome executable),?BSD?(source code and Chromium executable except chromium 5 beta),BSD License?with proprietary parts (source code and chromium 5 beta executable, as it integrates?Adobe Flash Player?10.1[1])[2] http://en.wikipedia.org/wiki/Google_Chrome in my?interpretation, this means Google Chrome is fully open-source, only the flash player has proprietary

On Fri, 6 Feb 2015, Ady wrote: > ... > But if we are talking about Chromebooks with SeaBIOS, are we talking > about booting kernels in CSM mode? Or in UEFI mode? > > Other than Chromebooks with (stock) SeaBIOS, is this new reported > behavior also seen under other cases / hardware / firmware / kernels > (versions)? Hi Ady, With a clone of the git repo on kernel.org I run

I'm thinking of buying a Samsung Chromebook, largely for use while travelling. But I'd like to use it at home linked to my CentOS-6.4 server, rather than to the cloud. I'm wondering if this is practicable? I use LaTeX quite a lot, and I don't know if I could (a) download LaTeX to the Chromebook, (b) run LaTeX on the cloud, or (c) run LaTeX on my server from the Chromebook. Has

Please favorite the following bug and express desire to have wav49 VoiceMails play natively in Google Desktop Chrome HTML5. https://code.google.com/p/chromium/issues/detail?id=465431 .WAV already plays in Android Chrome and Chromebook and others, but not the desktop version. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Renato, The tests below are target independent and should pass. Did you build the x86 backend ? I think that the problem is that opt uses the triple from the LL file to initialize the backends and the cost model, and if you don't have the x86 backend then the tests fail. I will fix the tests shortly. Thanks, Nadav On Jan 4, 2013, at 3:45 PM, Renato Golin <renato.golin at

I recently got a tegra TK1 and was curious how fast it was compared to my previous arm "build machine": the original arm Samsung chromebook. I timed running ninja to build just llvm in Release+Asserts using clang as the host compiler. chromebook: real 84m30.939s user 163m50.145s sys 4m0.100s TK1: real 34m7.376s user 132m44.417s sys 3m3.543s A really nice

On Thu, Feb 19, 2015 at 5:47 AM, Dennis Jacobfeuerborn <dennisml at conversis.de> wrote: > I think the problem is that you simply have to draw a distinction > between technology and product. > The rise of the Linux desktop will never happen because Linux is not a > product but a technology and as a result has to be a jack of all trades. I'm unconvinced. True, Chromebooks