LTSP 5 is in minimal maintenance mode
The new LTSP is hosted at https://ltsp.github.io

IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 7 November 2019   (all times are UTC)

00:50eddytv has joined IRC (eddytv!~eddy@2601:402:4500:4670:c954:cfa4:b07f:bd36)
00:51vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
03:05eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:c954:cfa4:b07f:bd36, Quit: My computer has gone to sleep. ZZZzzz…)
03:26pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv)
03:27pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Client Quit)
04:37dgroos has joined IRC (dgroos!~dagro001@63.225.132.145)
04:37dgroos has left IRC (dgroos!~dagro001@63.225.132.145, Client Quit)
05:40kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288)
06:34ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
06:37vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
06:55
<alkisg>
vagrantc: so, I think we can find everything locally except snponly.efi and memtest.efi. It's still not OK to wget just these two, right?
06:55
I.e. code that would search things locally, and fall back to https if they're not found, or even if the user passes a special switch
06:58
For example, `ltsp ipxe` wouldn't wget anything, and only rely on local things, while `ltsp ipxe --wget-missing-binaries` would prompt the user "downloading over https, verify them yourself..." and download either the missing ones or all of them if --wget-all-binaries is specified
06:59
Or we can just tell him "wget those missing binaries yourself: ..." and spout some wget commands for him
07:01* alkisg did like the download counter though :P
07:27kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288, Ping timeout: 276 seconds)
07:30
<highvoltage>
alkisg: memtest.efi doesn't work anyway
07:31
<alkisg>
highvoltage: hm? It worked for me... did I upload a broken version?
07:31
OK let me test
07:31
<highvoltage>
alkisg: not sure if you uploaded a newer blob since I last tried
07:31
<alkisg>
I didn't
07:32
Did you try on a single client?
07:32
E.g. maybe it does have some bugs and hangs on some clients...
07:33gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.27)
07:33
<highvoltage>
alkisg: I tried on a bunch of efi clients and they said something like "This version of memtest does not support pxe"
07:33
<alkisg>
highvoltage: did you load it with ipxe, or from e.g. grub?
07:34
<vagrantc>
alkisg: what do we miss not having snponly.efi ?
07:34
alkisg: i like the "--wget-missing-binaries" route ...
07:34
<alkisg>
vagrantc: it won't boot on many PCs
07:35
<vagrantc>
alkisg: where does snponly.efi come from?
07:35
<alkisg>
I think it's just a build target of ipxe, it should only involve a couple of lines changed in the debian ipxe package
07:35
There's the "BIOS/UEFI driver" and the "IPXE drivers"
07:35
snponly means "use the internal UEFI driver"
07:35
ipxe.efi means "use the IPXE drivers"
07:36
So if e.g. I have a marvel card or whatever, that ipxe doesn't have a driver for, and my uefi driver works fine, it'll need snponly.efi to boot
07:36
<vagrantc>
ok, let's get it enabled in the package ... but it does sound useful to have a wget option for distros that don't (yet) ship all the binaries
07:36
<alkisg>
Normally, we would never need ipxe.efi; but in some cases the internal UEFI driver is broken, and there ipxe.efi *may* work
07:37
vagrantc: right; so, to sum up on who does what:
07:37
You please do handle getting snponly.efi on debian ipxe,
07:37
and I'll do the code/documentation about preferring local ipxe.efi etc etc, then falling back to wget with some warnings etc,
07:38
but, I won't do the gpg stuff, ok?
07:39
<vagrantc>
that mostly sounds good ... just for clarity ... will the wget fallback be enabled by default? or will it just warn which are missing and mention the commandline option?
07:39
<alkisg>
vagrantc: I think that it should wget snponly.efi currently, as it won't find it on disk, with the appropriate message,
07:40
...actually, we can just do that with the --missing option in the documentation
07:40
So "ltsp ipxe" by default doesn't wget, but "following installation instructions" wgets snponly.efi
07:41
<highvoltage>
alkisg: I loaded it via ipxe
07:41
<vagrantc>
the important part to me is that it's clear when it's downloading unverified binaries and it's possible to opt-out somehow
07:42
<alkisg>
highvoltage: I see that too; will fix it tomorrow
07:42
<vagrantc>
so ... i'm inclined to supporting *some* verification method, if we don't yet have it more fully integrated
07:42
<alkisg>
I probably uploaded something else than what I tested
07:42
<highvoltage>
alkisg: cool
07:42
<alkisg>
vagrantc: OK, I'll need your help in that part too then (the gpg stuff)
07:43
<vagrantc>
alkisg: sure
07:43
<alkisg>
Feel free to commit not-very-tested code and I can test/tweak it later
07:44
<vagrantc>
alkisg: i'd say go ahead and do what you proposed, and then i'll have a better idea of where to hook in the verification
07:44kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288)
07:45
<alkisg>
OK, it'll take me a while though as I have some other things scheduled first... :/
07:45
<vagrantc>
sure
07:45
or i'll just dive in ... though sadly ltsp isn't high on my list still, despite being excited about the new version :)
07:45
<alkisg>
:)
07:46
<vagrantc>
maybe i have to actually do marketing to get clients who want ltsp :)
07:47
<alkisg>
Haha, I do think LTSP needs some up to date marketing
07:53statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
07:58woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de)
07:59enoch85 has joined IRC (enoch85!25f71ea4@37-247-30-164.customers.ownit.se)
07:59
<enoch85>
good morning!
08:00
<alkisg>
Good morning enoch85
08:02
<enoch85>
alkisg, been talking to my boss some more and we have 7 Windows Sessions Hosts (Terminal Servers) which we diveded up to several just to have a backup in case one SH would go down. Bringing LTSP to the table means that if the LTSP server goes down, all connections die (when I've tested at least) which makes the LTSP server a single point of
08:02
failure. To prevent that, would it be possible to make LTSP load "an image" every time the client reboots the client PC, and then run everything on the client PC so that if the LTSP server goes down the clients aren't affected?
08:03
<alkisg>
enoch85: sure, you can cache everything to ram when clients boots, both root / and the client home template, as long as RAM suffices
08:03
It'll need some code in LTSP19, it's not integrated yet, but just a bit
08:04
You may also install an nfs server on the windows servers
08:04
<enoch85>
hmm, the clients we have are mixed with 1 GB and 2 GB RAM, looking at the when running it holds about 700 MB, so it's a close call
08:04
<alkisg>
As you'll be needing that connection anyway
08:05
So both the image and home will be hosted on the windows servers themselves
08:05
<enoch85>
so I won't get aroun the fact that the client sessions die as long as I have NFS on the LTSP host?
08:05
<alkisg>
Your clients don't have a lot of ram, it's best to rely on NFS being available
08:06
One easy way is to have the clients select an NFS server out of multiple ones on boot. Windows servers may be NFS servers.
08:06
So that is both load balancing and avoiding the single point of failure
08:07
<enoch85>
we have several ubuntu servers in our server farm. I'm more a Linux guy than a windows guy actually... so what you're saying is that we could set up several small NFS servers and host /home/guest from there?
08:08
<alkisg>
Sure. ProxyDHCP replies can also do load balancing, so:
08:08
Suppose you replicate the ltsp server into 4 servers
08:08
Then the clients will boot from the one that replies first
08:09
<vagrantc>
alkisg: it looks ipxe is even building it, so it might just be a one-liner to actually install it in the package...
08:09
<alkisg>
(or you can configure where each client will boot etc)
08:09
vagrantc: great!
08:09
vagrantc: I can backport it to the ppa so then we won't need wget at all
08:09
(the ipxe package)
08:09
<vagrantc>
right
08:10
<enoch85>
alkisg so I replicate the LTSP server itself! but what about when I make a changes on the servers, how will that replicate to the other servers?
08:10
<alkisg>
enoch85: one way is to use cephfs
08:10
<enoch85>
each server would have it's own image right?
08:10
<alkisg>
OK when that part is ready, I can give you access
08:10
<enoch85>
hmm
08:10
<alkisg>
Sorry
08:10
<vagrantc>
alkisg: will try to build it to see exactly what's needed to fix the packaging when the time comes
08:10
<alkisg>
I meant this: https://github.com/ltsp/ltsp/issues/37
08:10
<vagrantc>
alkisg: but then i'll have to boot an x86 machine :)
08:11
<alkisg>
Haha :D
08:11
God forbid!
08:11
<enoch85>
lol --^
08:11
CephFS seems interessting,
08:11
<alkisg>
enoch85: so, you may set up 2 or 3 machines as ltsp servers, and have common /srv and common /home with cephfs for them
08:11
And boot ltsp clients with cephfs,
08:12
so that then if you power off one of the servers, the clients will continue working fine with the other 2 servers
08:12
<enoch85>
very interesting!
08:12
<alkisg>
No downtime, and automatic balancing
08:12
There's a bit of complexity involved, and a bit of extra syncing, but the end result is no downtime
08:12
<vagrantc>
yeah, cephfs is cool stuff
08:13
<alkisg>
enoch85: remind me, your clients also need to run a linux session with e.g. a local browser, right?
08:13
<enoch85>
alkisg how long would it take for you to put something like that togheter based on the fact that I already replicated the servers?
08:13
it only needs RDP, nothing else
08:13
it/they
08:13
<alkisg>
Then that's the wrong path
08:14
I thought you were trying guest accounts; RDP only is a different thing
08:14
For RDP only, you don't even need /home
08:14
I would suggest then that you have a minimal chroot/vm, with just rdp, so that it's around 500 MB compressed,
08:14
<enoch85>
the reason for the NFS stuff is that we would like to update the desktop icons from one account (guest)
08:15
1. Client boots the PC
08:15
<alkisg>
so that it's all cached in RAM, and then it just connects to one of the windows servers via load balancing or so
08:15
<enoch85>
2. Client sees 7 servers to choose from
08:15
3. Double clicks his/her server
08:15
4. COnnects
08:15
that's the whole idea
08:15
is there anything smarter?
08:15
<alkisg>
Yeah no need for guest accounts then
08:16
<enoch85>
hmm ok
08:16
<alkisg>
You can have a minimal chroot, loaded e.g. over NFS, then cached in RAM, then it'll show a login screen with those 7 servers
08:17
<enoch85>
how would we replace the servers in question? Just change the chroot and update the image?
08:17
would there still be a need for multiple ltsp servers and load balancing etc?
08:18
would the connection die if the server reboots with that soulution?
08:20
<alkisg>
No, it wouldn't die
08:20
After the client boots, the ltsp server may be powered off
08:20
<enoch85>
ok, then that sounds exactly what we would need
08:21
<vagrantc>
though NFS will hang indefinnitely waiting for the server to come back if it needs something that isn't yet cached...
08:22
<enoch85>
the only thing we will display for the end user is the 7 servers, and those won't change that frequeantly, maybe one new every 6 months or so
08:22
so alkisg how long time would you need to setup that soulution?
08:22* vagrantc waves
08:22vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
08:22
<alkisg>
bye va
08:22
grantc
08:23kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288, Remote host closed the connection)
08:23
<enoch85>
because then we could be running everything of one LTSP server since the client connection won't die upon server reboot or shutdown
08:23
<alkisg>
enoch85: I guess 2-3 days, depending on how much I need to do vs you do after my instructions etc
08:23
Yes, it'll all be cached in RAM
08:24
<enoch85>
I could do most of it if you instruct me I guess (hope)
08:24
<alkisg>
E.g. if you want me to write that python program with the 7 servers, or if you'll do it
08:24
Do you know python/gtk or something?
08:24
<enoch85>
aah, you woudl have to do that stuff, I didn't learn pything yet
08:24
pythion
08:24
python**
08:25
<alkisg>
Well, you do want a menu with 7 servers, right?
08:25
<enoch85>
I know bash somewhat https://github.com/nextcloud/vm
08:25
<alkisg>
I don't mean just the "cache to network" bit, I mean the whole solution
08:25
Up to the point where you boss says "excellent, all work fine"
08:25
<enoch85>
yes exactly
08:25
:)
08:25
<alkisg>
So, around 15-20 hours for all these
08:26
<enoch85>
ok, so 600€ ~
08:26
?
08:26
would it be easy for us to add and remove servers once it's deployed and done?
08:27
<alkisg>
Of course
08:28kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:6436:27c4:c18f:3cd)
08:28
<alkisg>
Yes, I can promise "no more than 600€ even if it takes longer", and if it takes less hours, it'll be less; we can also talk over PMs for the details
08:29
<enoch85>
yeah ok, I will talk to him and ask. we're on a tight budget here - even more tight as he will say "the current (old) soloution works" but it leaves ut with only being able to run Windows Server 2012
08:29
hehe
08:30
but why would python be needed? to programatically changed the servers page?
08:30
change*
08:30
(typing to fast)
08:31
<alkisg>
You need a login screen; what will provide it?
08:31
A nice dialog that displays the options to the users
08:31
Or does rdesktop have such a menu?
08:32
<enoch85>
I don't know if remmina would work
08:32
<alkisg>
That's one of the parts that you could do then
08:32
<enoch85>
problem with remmina is that it won't load dual screes
08:33
sec
08:33
<alkisg>
Research and see if you can have everything working, including a gui with options, with remmina
08:33
If not, then you'd tell me "program that via python/gtk"
08:33
<enoch85>
I stumbled across a script yesterday
08:33
will try to find it
08:33
<alkisg>
OK
08:33
<enoch85>
https://github.com/wyllianbs/xfreerdp-gui
08:34
<alkisg>
Anyway, I think we need to take the rest private; I'll do some other paid work in the meantime, you talk to your boss, and if he OK's it we continue with PMs
08:34
<enoch85>
maybe one could edit that to show the servers we would want
08:34
alkisg sounds good to me
08:34
<alkisg>
Great
08:34
<enoch85>
one last question
08:35
during my live tests from yesterday and today, the feedback is that it's very laggy, moving windows around is next to imnpossible e.g.
08:35
<alkisg>
Also check if you want "each pc to connect to specific windows servers", or "each user to connect to specific server", or "no, selectable"
08:35
You can test that with a normal installation that doesn't involve LTSP at all
08:35
<enoch85>
would this new soulution make it faster as everyting would be in RAM=
08:35
?
08:35
<alkisg>
No
08:36
<enoch85>
ok
08:36
<alkisg>
xfreerdp is faster than rdesktop afaik,
08:36
but RAM is about disk access, not about remote screen speed
08:36
<enoch85>
yeah ok
08:36
anyway, ttyl
08:37
<alkisg>
Your clients have intel GPUs if I recall correctly, right? So you just need to play with the correct programs/settings (xfreerdp, rdesktop etc) to make things as fast as you gen from there
08:37
*can
08:37
E.g. lowering bit depth to 16 might help
08:38
<enoch85>
yeah, been thinking about that, amongst other things
08:38
update rdesktop to latest as well
08:38
1.9.0 was just released
09:02Da-Geek has joined IRC (Da-Geek!~Da-Geek@5.154.189.38)
09:49GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 240 seconds)
10:19kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:6436:27c4:c18f:3cd, Remote host closed the connection)
10:23kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:6436:27c4:c18f:3cd)
10:52alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
10:52alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
10:55alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Client Quit)
10:57alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
11:26os_a has joined IRC (os_a!~Thunderbi@195.112.116.22)
11:39alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
11:39alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
11:40alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
11:45alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
11:45alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg)
12:01eddytv has joined IRC (eddytv!~eddy@2620:11e:1000:6:45f7:694d:eb04:3235)
12:05section1 has joined IRC (section1!~section1@178.33.109.106)
12:12Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49)
12:12Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:14GodFather has joined IRC (GodFather!~rcc@c-69-136-132-171.hsd1.mi.comcast.net)
12:22GodFather has left IRC (GodFather!~rcc@c-69-136-132-171.hsd1.mi.comcast.net, Ping timeout: 245 seconds)
12:32Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Remote host closed the connection)
12:35GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net)
12:36Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49)
12:36Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:44Da-Geek has left IRC (Da-Geek!~Da-Geek@5.154.189.38, Remote host closed the connection)
12:45Da-Geek has joined IRC (Da-Geek!~Da-Geek@5.154.189.38)
12:55Da-Geek has left IRC (Da-Geek!~Da-Geek@5.154.189.38, Quit: Leaving)
12:56Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Remote host closed the connection)
13:06Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49)
13:06Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
14:51alkisg1 has left IRC (alkisg1!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
14:51alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
14:55os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Read error: Connection reset by peer)
14:56alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
14:58woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Remote host closed the connection)
15:01alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
16:22douglas_br has joined IRC (douglas_br!bb5f6554@187.95.101.84)
16:24woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de)
16:35GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 240 seconds)
16:57statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
17:49vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
17:59
<vagrantc>
alkisg: i'm pretty sure rpi3b+ supports pxe booting without an SD card and without any special loading
17:59
alkisg: it can even load the boot firmware from the network
18:00
it's been a while since i've tested
18:00
<alkisg>
vagrantc: rpi4 shipped with broken network booting
18:00
I managed to netboot rpi3, but with many issues
18:00
...same with rpi2 with bootcode.bin on the sd card
18:01
<vagrantc>
yeah, rpi2 with bootcode.bin on the SD card
18:01
and boot firmware
18:01
(maybe)
18:01
<alkisg>
They're supposed to fix rpi4 firmware with the next release due in a few weeks
18:01
<vagrantc>
fwiw, i can test both rpi3b+ and rpi2b
18:01
<alkisg>
I have 3 rpi2, 1 rpi3, 1 rpi4
18:02
But I do not care enough to prepare ltsp for rpis without help of someone that uses them
18:02
I even advice schools here to avoid them,
18:02
<vagrantc>
so rpi4 will need an sd card when it's fixed? like rpi2?
18:02
yeah, i hear you
18:02
<alkisg>
and, when some school buys rpis and then realizes the folly, I send pentium 4's to the school to replace the rpis
18:02
No, rpi4 has flashable eeprom
18:02
<vagrantc>
ah
18:03
<alkisg>
What about other arm devices?
18:03
I think uboot had support for pxelinux.cfg style configs?
18:08
It'll be very nice if we don't have to support local kernels/initrds and just have bootcode.bin in the sd card
18:08
It'll save us the trouble of getting ltsp.conf via other means than ltsp.img
18:11
<vagrantc>
many recent systems support pxelinux.cfg style configs, yes.
18:11
recent systems on u-boot, that is, yes.
18:12
i'm not sure if they support multiple initrd images or not
18:12
now that accelerated graphics for a number of ARM systems is upstream, in really recent versions of kernel + mesa + other random stuff you might actually see reasonable performance for an LTSP client
18:13
at least in theory
18:35mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Remote host closed the connection)
18:39douglas_br65 has joined IRC (douglas_br65!bd4cccba@189-76-204-186-pdtst-cf-1.visaonet.com.br)
18:39
<douglas_br65>
hello all
18:40mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
18:43
<douglas_br65>
we put to work ltsp lab nice! but there are two screen out of resolution. yeah i did read the doc about ltsp xorg but i do not know how to start file or first read build xorg,sorry
18:44
<alkisg>
douglas_br65: upload the output of `xrandr` from the client
18:44
<douglas_br65>
thanks Mr. alkisg for all help
18:44
<alkisg>
Normally you just need X_MODES=´"1024x768" "800x600" "640x480"´
18:45
(in ltsp.conf)
18:45
<douglas_br65>
put this in ltsp.conf
18:45
ohhh right
18:47
<alkisg>
You can also use X_PREFERREDMODE="1024x768", but X_MODES is more compatible, even for older drivers, vesa etc
18:48
<meo>
re raspberry as far as I understand 3b is bootable with one time fuse enable, 3b+ is bootable by default
18:49
i have a couple of 3b+ so i can play with ltsp on it
18:49
<douglas_br65>
put this in the client line yeah?
18:49
<alkisg>
yes
18:50
meo: it has various issues, it's not very stable etc; personally I'll just wait until someone that really needs to use it comes along
18:50
lack of time, thousands of things to do etc
18:51
<meo>
well sure
18:51
the use case is attractive enough for commercial purposes
18:52
e.g. call centers at 100 eur/seat for hardware and 0 license costs for software
18:53
<alkisg>
rpi was already supported by ltsp for years; we didn't hear about such use cases
18:54
And 2 call centers that I know of, need windows VMs to run their programs :/
18:54
Let's hope they'll find uses for it, sure :)
18:54
<meo>
I have a call center that runs on your ltsp
18:55
the profile is narrow
18:55
<alkisg>
With no windows? Which software are you using?
18:55
<meo>
web-based crm, linphone for sip, flock for internal comms
18:56
if you have live chat software or a desktop client crm, yeah that's out of the window
18:56
but as long as you're web based, it works
18:57
we are in fact considering converting the other, larger call center
18:58
but this is mostly due to the business owner not wanting to pay microsoft to upgrade win 7 to win 10
18:59
the other thing is that rp2 isnt realistically powerful enough for daily desktop usage
18:59
3 is getting there and 4 would work near perfectly
18:59
<alkisg>
One of my clients used linphone but had to change it with five9
19:00
So at that point we had to install windows VMs
19:00
rpi2 is a bit slower than pentium 4's
19:00
rpi4 is like old atoms, almost usable
19:01
but for 50 euros one can buy a refurbished pc that's 10 times faster
19:01
even in small form, low power etc
19:01
In any case it was good to see rpi4 almost usable
19:01
<meo>
true, although in variances and not as available everywhere
19:01
<alkisg>
With the new graphics drivers in a few years, it'll be ok
19:01
<meo>
I did look at refurbished PCs locally
19:01
(Bulgaria)
19:01
<alkisg>
!cheap-client
19:01
<ltsp>
cheap-client: https://www.gearbest.com/tv-box-c_11262/?attr=2081-1279
19:01
<meo>
100-150 eur range
19:02
<alkisg>
There are also tv boxes that are faster than rpis
19:02
with similar prices
19:02
(atom based)
19:02
<vagrantc>
alkisg: i was overly optimistic about snponly.efi being built already.
19:02
<alkisg>
Ouch :/
19:03
<douglas_br65>
alkisg put the 3 option together or only 1024x768
19:03
<vagrantc>
alkisg: the driver is included in the all drivers target, though
19:03
<alkisg>
douglas_br64, I'll need the output of xrandr to tell you. What kind of screen, TFT, old CRT..?
19:04
<douglas_br65>
tft
19:04
<vagrantc>
alkisg: where'd you get snponly.efi from?
19:04
and how did they build it?
19:05
<alkisg>
vagrantc: from boot.ipxe.org/snponly.efi
19:05
I guess they're building all targets
19:05
But there's also `make snponly.efi` or something
19:06
<vagrantc>
make: *** No rule to make target 'snponly.efi'. Stop.
19:07
<alkisg>
I don't recall the syntax off-hand
19:08* vagrantc asks in #ipxe
19:10
<douglas_br65>
I will come back tomorrow and will study about tonight, thanks alkisg
19:10
<alkisg>
np
19:12douglas_br65 has left IRC (douglas_br65!bd4cccba@189-76-204-186-pdtst-cf-1.visaonet.com.br, Remote host closed the connection)
19:19
<vagrantc>
alkisg: ok, i have it built!
19:19
<alkisg>
Yey!
19:20
<vagrantc>
a one-liner
19:22
alkisg: i don't even know how to test that it's useful, but i can upload it for you somewhere
19:23
<alkisg>
vagrantc: sure, I'll be able to test tomorrow morning
19:23
Or maybe someone else here can test sooner
19:24
<vagrantc>
https://misc.aikidev.net/ipxe-WLqm8Vh/
19:24
<alkisg>
(if you have an ltsp19 setup,you'd just need to overwrite /srv/tftp/ltsp/snponly.efi with it, and boot an uefi client)
19:25
<vagrantc>
the first part i figured i could do, the second part i'd have to figure out how to do that with a virtual machine or something
19:26
<alkisg>
I think it's rather easy in kvm but not in vbox... so I just skipped that and used real uefi clients :D
19:26
<vagrantc>
ok, let's fire up my ltsp19 setup...
19:29
<alkisg>
downloaded, will test it tomorrow
19:31
<vagrantc>
hmmm.. where's my ltsp19 setup :)
19:47kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:6436:27c4:c18f:3cd, Ping timeout: 246 seconds)
19:47
<vagrantc>
alkisg: sent the bug and CCed you ... can always mention that you've tested the updated change.
20:00section1 has left IRC (section1!~section1@178.33.109.106, Quit: Leaving)
20:00douglas_br has left IRC (douglas_br!bb5f6554@187.95.101.84, Remote host closed the connection)
20:03
<alkisg>
vagrantc: ty, will do tomorrow morning; if you can comment there too it'll be nice: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927783
20:03
It's been 6 months now with no feedback there...
20:20
<vagrantc>
alkisg: not much to say, it kind of speaks for itself (other than not using "diff -u")
20:20
alkisg: hopefully some new, simple bugs will nudge a new upload...
20:21
alkisg: i guess i can basically add a "tested-by" :)
20:21
though all this EFI is newish to me
20:22
my most modern laptop uses coreboot, my second most modern uses EFI but only under the hood, but in bios emulation mode with no way to disable
20:24
alkisg: i've got a kvm booted machine with tianocore, but it's not loading snponly.efi ...
20:26
i guess i'll wait for you to test if i can't figure it out
20:31
<alkisg>
vagrantc: does ipxe.efi work there?
20:33
<vagrantc>
alkisg: it doesn't download it via tftp ...
20:34
<alkisg>
Sounds broken
20:34
<vagrantc>
in the dnsmasq logs, it loads ltsp.ipxe, vmlinuz, ltsp.img and initrd.img and then boots
20:35
i'll wait for you to get a chance to test, sounds like :)
20:35
<alkisg>
Sure, tomorrow morning
20:36
<vagrantc>
although it only supports bin-x86_64-efi/snponly.efi ... but i guess i686 didn't tend to support EFI commonly
20:37
<alkisg>
x86_32-efi is indeed rare
20:51Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
21:03eddytv has left IRC (eddytv!~eddy@2620:11e:1000:6:45f7:694d:eb04:3235, Ping timeout: 264 seconds)
21:08eddytv has joined IRC (eddytv!~eddy@2620:11e:1000:220:35e4:d10e:ace1:afb9)
21:12woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection)
21:20ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:53eddytv has joined IRC (eddytv!~eddy@2601:402:4500:4670:7d06:3999:2510:c592)
22:02GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com)
22:40eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:7d06:3999:2510:c592, Quit: My computer has gone to sleep. ZZZzzz…)
22:50eddytv has joined IRC (eddytv!~eddy@2601:402:4500:4670:7d06:3999:2510:c592)
23:16eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:7d06:3999:2510:c592, Quit: My computer has gone to sleep. ZZZzzz…)
23:22eddytv has joined IRC (eddytv!~eddy@2601:402:4500:4670:7d06:3999:2510:c592)
23:22eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:7d06:3999:2510:c592)
23:42
<vagrantc>
alkisg: i have a fear i'm going to end up ipxe maintainer in debian again...
23:44
well, not again...