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


Channel log from 13 May 2018   (all times are UTC)

01:07lucas__ has joined IRC (lucas__!~lucas@177-185-141-105.isotelco.net.br)
01:07lucas_ has left IRC (lucas_!~lucas@177-185-141-105.isotelco.net.br, Read error: Connection reset by peer)
02:50aheyde has joined IRC (aheyde!~aheyde@2001:44b8:311a:af05:d0a4:355f:fe97:6575)
02:51
<aheyde>
Hi All, Does anyone know where I can find out about NBD/ AOE implementations for fat client root?
03:21
<vagrantc>
what do you need to know?
03:26
<aheyde>
So far I have just stumbled across ltsp-AOE in pxelinux.cfg dir - prior to this I had no knowledge of it being an option as it seems that NBD/NFS are the only ones mentioned in docs - unless of course I'm looking in the wrong place?
03:27
<vagrantc>
it's not really documented
03:27
<aheyde>
In theory, my reading about AOE suggests that it should be a good option providing I have jumbo frames
03:27
no problem - is that because it isn't a good option, or?
03:28
<vagrantc>
you can actually configure the same ltsp image to use either AoE or NBD ...
03:28
the only real difference are the boot arguments passed
03:28
if i'm remembering correctly ... it's been quite a while since i tested
03:28
<aheyde>
I can see why NBD is preferable to NFS, (block level vs file)
03:29
based on my reading, it would seem like AOE should be even better than NBD in terms of latency etc
03:29
So I guess I'm looking for opinions/ tests / background as to why NBD not AOE is default etc
03:31
<vagrantc>
alkisg would know better the limitations; experimented with it more
03:32
NBD was supported in LTSP longer, and so, if for no other reason than time, it's still the default
03:33
<aheyde>
Makes sense. In that case it probably was due to perceived improvements that AOE was even added.
03:34
<vagrantc>
it has some other interesting qualities ... since it's not TCP/IP based, it means you can actually just use networking without worrying about it taking down your rootfs
03:34
just because you took down an interface ... although there still maybe was some issue around that ... e.g. if the link status was manually taken down
03:36
<aheyde>
I'm not quite sure what you mean, but I think it is that because it is connection-less, short interruptions on the network interface (such as bringing it down then up) don't cause a permanent failure?
03:37
(Thank you for your responses btw, has already been very helpful)
03:45
<vagrantc>
it operates at a lower layer and has no ip addresses
03:45
so you can use a dhcp client, and it won't kill your rootfs if your lease expires and you get assigned a new ip address
04:16vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
04:27alkisg_android has joined IRC (alkisg_android!~yaaic@2a02:2149:842e:c700:2ce6:90cd:bdc8:3345)
04:29
<alkisg_android>
aheyde, aoe isnt good when server is gigabit and clients fast ethernet
04:29
as it cant use tcp rate limiting, so its 10 times slower than nbd there
04:30
on nets of same speed anywhere, its great
05:14alkisg_android has left IRC (alkisg_android!~yaaic@2a02:2149:842e:c700:2ce6:90cd:bdc8:3345, Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org)
06:01TheBoyd has left IRC (TheBoyd!~TheBoyd@2605:a601:652:9500:892e:e98a:7311:2174, Quit: Leaving.)
07:09TheBoyd has joined IRC (TheBoyd!~TheBoyd@2605:a601:652:9500:1586:258d:f2dd:a2ee)
07:14
<aheyde>
Hi alksig, thanks for the response.
07:14
I'm likely to be going for 4x 1Gb on server and 40 x clients at 1Gb
07:15
I guess I would have the same problem if I went for 10Gbit on server and 1 Gbit on clients?
07:17
Although perhaps server wouldn't be able to send fast enough to overwhelm the 1gbit speed change in the switch anyway
07:18
I'm guessing you are refering to the problem where the server sends much faster and frames are dropped on the switch?
07:20eemeli has joined IRC (eemeli!d442dd17@gateway/web/freenode/ip.212.66.221.23)
07:21
<alkisg>
aheyde: use tab in irc to autocomplete the user names to get them right so that they know you're talking to them :)
07:21
!flow
07:21
<ltsp>
I do not know about 'flow', but I do know about these similar topics: 'flow-control'
07:21
<alkisg>
!flow-control
07:21
<ltsp>
flow-control: https://help.ubuntu.com/community/UbuntuLTSP/FlowControl
07:22
<alkisg>
So, the flow control problem can be solved at the TCP/IP level, but not at the ethernet level
07:22
Because at the ethernet level, when a client tries to say "don't send more data I'm overwhelmed", the server stops sending to ALL clients, not on the specific client only
07:23
NBD in general is stable (except for a few glitches in the recent years), so there hasn't been any need or benefit for defaulting to aoe
07:24
Some switches are even optimized to work faster with nbd rather than aoe
07:27eemeli has left IRC (eemeli!d442dd17@gateway/web/freenode/ip.212.66.221.23, Ping timeout: 260 seconds)
07:34
<aheyde>
alkisg, thanks for your helpful responses - could you elaborate on your last point?
07:38
Theoretically, I would think that aoe should therefore be a preferred option for all 1Gb connections (with jumbo frames) due to decreased overhead and latency reduction, any comments on that suggestion?
07:43
<alkisg>
aheyde: if by overhead you mean the additional tcp/ip headers, how much it that, 1%?
07:44
In practice, on gigabit connection, with nbd I'm getting 960mbps and with aoe 900. It depends on a lot of things though, in certain setups you might see the opposite
07:44
<aheyde>
I guest I'm less concerned with throughput
07:44
more so latency
07:45
So when I say overhead I'm more concerned with cpu overhead/ delay in tcp/ip stack etc
07:45
I thinking in terms of client responsiveness opening applications
07:45
<alkisg>
When transferring at 1 gpbs, the cpu doesn't need more than 1%, so what overhead?
07:46
The client opens apps as fast as if it was using a 100 MB (bytes)/sec disk; a bit faster than rotational one, but of course not as fast as ssd
07:46
I don't think you'll see any measurable difference if you use nbd/aoe on a 1 gbps network
07:47
<aheyde>
Perhaps I should take a different angle - I'm looking to build a highly scalable and performance system so trying to determine best approaches to get the best result
07:48
<alkisg>
OK, give it some though for places where you can actually see a difference of more than 1%, not in nbd/aoe
07:48
*thought
07:48
If you give more details on your setup and expectations, we might be able to propose places where you can optimize
07:49
<aheyde>
Sure, if there really isn't any measurable difference that is fine :)
07:49
<alkisg>
There'a a HUGE difference with 1 gbps server and 100 mbps clients, where nbd is 10 times faster
07:49
Other than that, it's pretty similar
07:49
<aheyde>
ok.
07:49
100mbit client was never an option for me
07:50
<alkisg>
Same for 10g server and 1 g clients
07:50
Or even for 4g server and 1g clients
07:50
(bonding etc)
07:51
Hmmm actually I'm not sure about the bonding case, it might be the same, needs some thought
07:51
But no real benefit in aoe anyways
07:51
<aheyde>
ok
07:52
I like the idea that AOE is not dependent on IP as mentioned above for DHCP leases (although minor)
07:52
but also that I can intelligently deal with multipath/multihomed nics without bonding
07:52
it*
07:53
<alkisg>
aheyde: all these sound too theoretical, do you have a working ltsp setup?
07:53
When the client ifdowns a NIC, it will stop working even if it's using AoE
07:54
So the benefit isn't as great as it initially sounds; changes in the client networking stack are needed anyways
07:54
*networking configuration
07:54
<aheyde>
I have a working setup with a few clients, and a working test setup with a single client on which i'm experimenting
07:55
<alkisg>
Even when using aoe, ltsp configures the networking in the same way as nbd
07:55
So unless you're trying to do your own implementation, it doesn't make much of a difference
07:56
<aheyde>
I guess how much I would or wouldn't implement depends on whether there are any major gains in doing it differently
07:57
My thought was that someone at some point implemented AOE hoping to do something better - or why bother in the first place?
07:57
<alkisg>
AoE doesn't need a client to be activated. nbd-client might not be available anywhere. That's why I added support for it in ltsp.
07:58
If you mean aoe in general, why there are 300 linux distros? Each hopes to do something different.
07:59
I'm sure there are a lot of cases where aoe would be great, e.g. embedded systems or whatever. In ltsp, it doesn't make a lot of a difference.
08:00
I might also add support for iscsi targets in ltsp; that also won't mean they'll be much better than nbd
08:00
<aheyde>
Fantastic - that background is useful - first knowing that you added it, and second to see that it was really for compatibility/flexibility rather than performance
08:07
In terms of performance in general then - perhaps I should ask about where you would look to optimise performance both for thick and thin use cases
08:09
<alkisg>
Where _are_ you having performance issues? I haven't understood...
08:09
If you're talking about "optimizing linux performance in general", that's not the right channel here
08:10
If you're talking about "oh, ltsp goes much slower than a normal hard disk installation for me", then yes, it's the right channel
08:10
<aheyde>
yes ltsp specific
08:10
<alkisg>
So you have a client that if you use a disk it goes faster than when it's using ltsp?
08:11
<aheyde>
I have a client with with AMD A6-1450 and 4Gig Ram
08:11
I have the same 18.04 MATE desktop on an on board SSD and also using this machine as LTSP client
08:12
current test server is i7 with raid 0 ssd (so should be at least as fast as client local ssd)
08:13
<alkisg>
And what test are you using to measure a difference? E.g. how much time it takes to open firefox?
08:13
Or e.g. hdparm -t /dev/nbd0 ?
08:19
<aheyde>
just user perception so far - I will certainly need to carry out a myriad of measurements though.
08:19
(like launch times of apps yes)
08:20
<alkisg>
OK, please run hdparm -t /dev/sda on the ssd, and hdparm -t /dev/nbd0 on the ltsp client, and ping me once you have those numbers
08:21
If the SSD can do 500 MB/sec, which is more than 4 gbps, and your network can only do 1 gbps, then of course the SSD will be faster, even without comparing latency
08:21
In which case, you could use the local SSD for caching the LTSP image.
08:22
<aheyde>
Thanks I will certainly do those investigations
08:22
more broadly, more broadly, I'm also weighing up whether to go fat client with a few select remote apps
08:22
or thin client with a few select local apps
08:23
most docs I've been reading recently seem to be suggesting fat clients as much as possible even if clients are relatively low power
08:24
I'm currently planning to go with 'fat' clients and remoteapps where i wish to have more poewr
08:25
<alkisg>
What is your client cpu exact model, so that we see its cpubenchmark.net score?
08:25
AMD A6-1450 ?
08:25
<aheyde>
yes\
08:25
low power mobile chip
08:26
<alkisg>
https://www.cpubenchmark.net/cpu.php?cpu=AMD+A6-1450+APU&id=1908 says 1522. It will run better as a fat client rather than a thin one, for most apps, like browsing etc.
08:26
If you need math-related apps, you might consider a few remoteapps
08:27
<aheyde>
Yes - so for web browsing for example, I tried in thin mode - and while I *can* run full HD youtube videos in thin mode - it is silly as it takes almost the full 1gbit
08:27
clearly this will not scale well for 40 clients
08:27
<alkisg>
No, you can't properly run full hd youtube in thin mode
08:28
You lose a lot of frames that you might or might not notice
08:28
!flash
08:28
<ltsp>
flash: Yes, flash sucks. An HD full screen 30 fps video needs 2.5 Gbps bandwidth (1920×1080×4×30)! Make sure you have LDM_DIRECTX=True in your lts.conf file, or if it's just youtube you're after, try some flash replacing plugin like http://linterna-magica.nongnu.org
08:28
<alkisg>
Do you have 2.5 gbps? I guess not
08:28
(not specific to flash, but to hd in general)
08:29
<aheyde>
Perhaps I was dropping some frames - certainly looked fine though - but not scalable.
08:29
curious as to the 4*30 in the calculation?
08:30
<alkisg>
30 fps, 4 bytes for each pixel (32bit color depth)
08:31
<aheyde>
ah cool 32bit depth
08:31
think i was at 16bit, but not sure... could have been why I got decent playback with 1gbit
08:32
either way it is clear that local video decoding is much more sensible
08:33
<alkisg>
No fat client runs on 16 bit by default
08:34
Ah sorry thin, yes, those run on 16 by default
08:34
It's still more than 1 gbps
08:34
<aheyde>
yep sure...
08:35
I'm thinking then perhaps to run web browsing local but most "work" apps with small graphics load centrally
08:35
<alkisg>
Is your server 20 times faster than your clients?
08:35
<aheyde>
ie. Libreoffice, and even non video graphics apps
08:35
<alkisg>
Can it perform better than 20 client CPUs?
08:35
If not, don't bother
08:35
<aheyde>
server will be 1950X threadripper with 64Gig ddr 4 ram
08:36
<alkisg>
https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+Threadripper+1950X&id=3058 => 22076 score
08:36
It's a monster. I wouldn't buy it, I'd invest on better clients :)
08:36
The thin client model won't work well nowadays where the LAN is so much slower than disks
08:36
and than HD displays bandwidth requirements
08:36
<aheyde>
interesting
08:37
<alkisg>
That's why the next ltsp won't even support thin clients at all
08:38
Note that selecting cells on libreoffice or doing presentations might require 1 gbps for each client anyway
08:38
So if you assume that libreoffice doesn't need a lot of network bandwidth for thin clients, this is not the case
08:38
<aheyde>
interesting
08:38
<alkisg>
For typing a few letters in writer, sure, it's excellent, but if you start scrolling it's 1 gbps
08:39
<aheyde>
well this is most usefull info thanks.
08:39
<alkisg>
np
08:45
<aheyde>
you meantion next ltsp won't support thin mode - will you still include remote apps support?
08:50Statler|Home has joined IRC (Statler|Home!~Georg@p5489740C.dip0.t-ipconnect.de)
08:54
<alkisg>
aheyde: ltsp development currently has a few issues, so it's hard to tell when and what will be implemented
08:55
<aheyde>
but essentially you are saying that you see no value in the thin model in any circumstance these days?
08:55
<alkisg>
Of course not, it's fine for making math clusters etc
08:55
But for desktops, not much
08:58
<aheyde>
Sure. So equivalently it is still completely appropriate for development workstations where most load is compilation etc, but not for anything with heavy graphics
08:58
<alkisg>
Well as a developer I don't want my workstation to lag
08:59
So I wouldn't use it as a thin client. I'd just arrange for the compilation to happen remotely e.g. over ssh
08:59
<aheyde>
sure.
08:59
cool
09:30
alkisg, you previously stated "The thin client model won't work well nowadays where the LAN is so much slower than disks". I'm just trying to fully make sense of this
09:31
If i'm not mistaken, you were really saying that the thin model doesn't work as the graphics bandwidth is now so much higher than LAN can handle
09:33
Please correct me where my understanding is confused.
09:34
I would think that in the THIN case, graphics traverses the lan and disk access is "local"
09:34
In the THICK case, disk access is over the lan and graphics are local
09:39
such that it is in the THICK case where LAN to DISK speeds are relevant
09:39
and in the THIN case where graphics to LAN speeds are relevant
09:39
<alkisg>
aheyde: yes, in thins we compare lan to screen bandwidth => i.e. very bad comparison for thins, and in fats lan to disk speed => i.e. comparable to rotationals currently, while it might benefit with local image caching on ssd disks in the future
09:39
So for fats there isn't a big issue
09:41
<aheyde>
I find it somewhat surprising that LTSP is moving to the thick only model just as VDI and the concept of remote desktops seem to be gainingn broader acceptance (after a long "pc centric" view)
09:42
I guess here I'm thinking of many low bandwidth protocols for VDI desktops by large vendors
09:43
etc.
09:44
To your knowledge has anyone explored the integration of XPRA or similar to lower bandwidth for thin use cases?
09:46
<alkisg>
I think I tried xpra 5 years ago or so, it's the same as all other protocols, nx, rdp...
09:46
I.e. extremely slow and unusable for real desktops
09:47
For services that you cannot have in a client pc and so you're forced to use remote desktop, sure, people will lower their expectations and use those
09:48
But I'd never use a remote VDI to watch youtube videos
09:48
The main concept of ltsp for me is, "maintain a single installation"
09:48
While for VDI's that's not the case
09:49
<aheyde>
Understand. So the "fat" client mode keeps the "easy maintenance" benefit - that being the primary goal
09:50
<alkisg>
Both thins and fat clients offer easy maintenance
09:50
But nowadays the thin client model isn't appropriate for desktop use
09:50
That's why we don't recommend it anymore
09:51
If in the future, it gets possible for a server, to stream e.g. 20 compressed video streams realtime, it might make sense to use thin clients again
09:51
<aheyde>
I guess that is what I really want to understand, as most newer (even very low power chips) have harward video decoding
09:51
<alkisg>
For example, sony uses nvidia GPUs and is able to offer remote gaming
09:52
But I don't know of any server that can ENCODE 20 HD video streams in real time
09:52
Not even your monster
09:53
<aheyde>
I was rather thinking pass through where it is relevant i guess
09:53
or adaptive streaming
09:53
<alkisg>
I've no idea what "pass through" would mean for thin clients
09:53
You scroll a libreoffice window
09:53
There's no video stream
09:54
The server needs to generate one and send it compressed so that it doesn't need 100 gbps lan
09:54
Or you play a game. Same idea.
09:55
<aheyde>
I guess I was meaning selective encoding of video where it is needed but not all the time
09:56
It seems XPRA is now doing this type of thing (but I haven't tried it yet)
09:57
<alkisg>
It's still software
09:57
You need hardware for remote desktop to be suitable for normal users
09:58
You can spend months comparing software; it won't make any real difference
09:58
It might make 20% or 40% of use cases nice, but it'll never fit 90%-100% of desktop use cases
09:58
<aheyde>
Just to make sure I've got this straight, you are saying to get useable remote desktop you would need hardware encoding?
09:59
I see.
09:59
<alkisg>
So it's not even worth the time TALKING about it anymore :)
09:59
Yes, I'm saying exactly that
09:59
For example, a long hdmi cable is a very good implementation of "remote desktop"
10:00
It's compressed using hardware
10:10
<aheyde>
To round out the exploration of efficient computing - in the original 'thin' ltsp concept - pooling of resources was a key feature - ie. individual clients were able to use a large percentage of server resources if there was low contention/ low number of clients active
10:11
Given we have concluded that the 'thin' concept is not usable these days, I'm curious if anyone has explored pairing 'fat' ltsp clients with multiseat setups? (To achieve some of the same economies of scale)
10:11
<alkisg>
I've implemented multiseat support in ltsp 2 years ago
10:12
<aheyde>
Fantastic - do you know if it has had much uptake? challenges etc?
10:12
Perhaps this is the model I am ultimately looking for
10:12
<alkisg>
I've no idea why you don't just prefer normal clients
10:13
Multiseat setup works fine with ltsp, no challenges left unanswered
10:13
<aheyde>
Well I may, once I properly explore viable alternatives
10:14
<alkisg>
Whatever "weird" you select will just bite you due to "less mainstream => more problems/less support"
10:14
But if you prefer that, sure go for it
10:14
<aheyde>
I'm ultimately exploring this whole technology stack for implementation in cash constrained 3rd world applications
10:14
<alkisg>
!cheap-client
10:14
<ltsp>
cheap-client: https://www.gearbest.com/tv-box-c_11262/nt1_windows~10/
10:14
<alkisg>
Buy them cheap normal clients
10:15
Whatever you do, whatever you search for, will be have lower cpu/price ratio than the most mainstream solutions
10:15
Because mass production ==> more cpu in less price
10:17
<aheyde>
Yes this makes sense.
10:17
I questioned multiseat as multidisplay machines are now very mainstream and almost standard so I believe these will likely align
10:18
<alkisg>
Whoops the link went dead
10:18
Multiseat doesn't work well with multidisplay machines
10:18
It works well with multi GPU machines
10:18
Which end up more expensive than the cheap clients
10:18markit has joined IRC (markit!~marco@mail.ammdomus.it)
10:19
<alkisg>
This is a software limitation though; maybe in 5-10 years this won't be the case anymore
10:19
<aheyde>
understood
10:19
<alkisg>
!forget cheap-client
10:19
<ltsp>
The operation succeeded.
10:20
<alkisg>
!learn cheap-client as https://www.gearbest.com/tv-box-c_11262/?attr=2081-1279
10:20
<ltsp>
The operation succeeded.
10:20
<alkisg>
Example: https://www.gearbest.com/media-player/pp_691661.html?wid=1433363 => 67 euros, atom, 2 gb ram
10:20
Two of them cost 130 euros
10:20
A multiseat pc with 2 seats costs more
10:21
So for third world deployments, use tv boxes
10:21
They have the best cpu-to-cost ratios
10:24
<aheyde>
ok. Guess that is much the same as the AMD A6-1450 I was already mentioning then.
10:24
<alkisg>
Yes, just cheaper :)
10:25
It's the bare minimum for fat clients, surfing etc
10:25
<aheyde>
I'm purchasing for under 100US$ with 4GIG ram so I think that is comparable
10:25
<alkisg>
With a box and everything?
10:25ricotz has joined IRC (ricotz!~ricotz@p5B2A87F4.dip0.t-ipconnect.de)
10:25ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
10:25
<aheyde>
Direct from china yes
10:26
<alkisg>
For schools here I recommend fat clients with at least 3000 cpubenchmark score, but for third world atoms could make sense
10:26
Yeah then both are directly from china
10:26
<aheyde>
yep cool.
10:27
<markit>
alkisg: hi, I've the feeling that tv boxes are very "closed/locked" and you can't install GNU/Linux there (or pxe boot)
10:27
<alkisg>
markit: the link I give is for windows boxes, which means x64, where linux works fine
10:27
I'm not proposing android boxes, exactly for what you said
10:28
<aheyde>
Thanks for all your time alkisg, I'm not meaning to ask silly questions, but rather explore all the boundaries and assumptions.
10:28
<markit>
alkisg: aren't the bios "locked" to Win10 or something like that?
10:28
<alkisg>
markit: I haven't ever heard something like that, no
10:28
How can you lock UEFI?
10:28
<markit>
I would not assume that because they run M$Chanis they will run GNU/Linux too, you do?
10:29
<aheyde>
I take this approach as, for example, in most situations i'm come across, people spec standard desktops without weighing up any of the features, limitations, management considerations etc.
10:29
<alkisg>
Yes, I do, and for as many cases as I know, it's true
10:29
I don't know of any UEFI-based x64 hardware that can't run Ubuntu
10:30
aheyde: I've spend years researching all those, so I've pretty much made up my mind about the best options
10:50
<aheyde>
alkisg, can certainly appreciate that.
10:54
If I was to drop the remote apps entirely - what sort of spec are you recommending for 40 machines for a FAT only setup?
10:55
(I have of course read documents in the wiki - seems it is all quite old though, hence the question)
10:55
Really the only task is a file server, so specs should be modest i guess
11:05edgar^edgar-MS-7 has joined IRC (edgar^edgar-MS-7!53269497@gateway/web/freenode/ip.83.38.148.151)
11:09
<alkisg>
aheyde: remote apps is basically ssh -X server app; they'll run fine as long as you're using xorg and not wayland
11:10
aheyde: for schools, I propose clients with at least 3000 score (and usually just i3's), and servers with 5000+ score (usually i5's with 8 GB RAM)
11:10
And that's only because the server is also the teacher pc
11:10
<aheyde>
Thanks alkisg, I see.
11:11
<alkisg>
One thing you could optimize, is using nfs instead of the default sshfs for /home, as sshfs takes up a bit of cpu
11:11
<aheyde>
Do you have any idea of server requirements in terms of CPU if it is ONLY for serving root / home
11:11
What is the background on SSHFS for home as standard?
11:12
<alkisg>
Security; nfs 3 didn't support encryption
11:12
<aheyde>
clear . thanks
11:12
<alkisg>
For NBD/NFS only, you could use even an atom server
11:12
No CPU requirements there
11:13
<aheyde>
I guess that is where my thought process was headed... if moving to completely fat model even http://www.hardkernel.com/main/products/prdt_info.php?g_code=G150229074080 may suffice
11:13
<alkisg>
Again with the "non mainstream" tactic :)
11:13
It'll bite you...
11:13
<aheyde>
(yes i'm aware of the ARM architecture etc - I'm assuming externally generated images)
11:14
Fair enough - I'm assuming you have had your fair share of "bites" in the past?
11:14
<alkisg>
Sure
11:14
Where my reply usually was, "throw them away and buy a pc"
11:15
<aheyde>
by this you refer to other people asking for support with non standard hardware? or your own personal efforts to use non mainstream solutions?
11:15
<alkisg>
Lots of the first, lots of the second
11:17
<aheyde>
If you don't mind me asking, which areas did you try to optimise for which backfired?
11:19
<alkisg>
Sorry, but I don't have more time today for free support; I need to do some work :)
11:19
Some other day maybe
11:19
<aheyde>
No worries.
12:28Statler|Home has left IRC (Statler|Home!~Georg@p5489740C.dip0.t-ipconnect.de, Remote host closed the connection)
13:00GodFather has left IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net, Ping timeout: 240 seconds)
13:13GodFather has joined IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net)
13:15aheyde has left IRC (aheyde!~aheyde@2001:44b8:311a:af05:d0a4:355f:fe97:6575, Remote host closed the connection)
13:27markit has left IRC (markit!~marco@mail.ammdomus.it, )
13:34octoquad has joined IRC (octoquad!~octoquad@197.231.147.54)
13:34
<octoquad>
Hi, sorry I disappeared yesterday after asking a question. My question was if there is work around for gdm3 on tty1 not stealing focus from ldm on tty7 in Ubuntu 18.04 fat clients? I have tried a few things to prevent this, but completely disabling gdm in systemd prevents the lock screen from working.
13:48GodFather has left IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net, Ping timeout: 246 seconds)
13:48
<alkisg>
octoquad: usually, mate is recommended. Not many devs are using/testing gnome with ltsp
13:56
I'll be deploying a couple of schools with gnome in September; I'll start bug squashing around then
14:06
<octoquad>
Thanks alkisg, I've just advised a client for the time being to just switch to tty7 manually at boot with CTRL+ALT+F7 until this is resolved.
14:07
Are there any plans for fixing NBD for shutdown and restarting in 18.04 that's also a small prblem at the moment.
14:08
For DNS, we just the systemd resolved configuration file, which get's copied into the chroot at build time. There is an open bug report already for that.
14:20
<alkisg>
octoquad: new ltsp releases with those fixes might arrive in september
14:22
<octoquad>
alkisg, that's great news. If you would like more hands for testing, let me know, I'm keen to help out if need be.
14:22
<alkisg>
octoquad: testing is always good, but patches/coders are the ones most needed
14:22
<octoquad>
alkisg, you can message me from launchpad any time.
14:23
<alkisg>
I have 1000 schools, enough testing here, but noone helps with the coding
14:24
<octoquad>
alkisg, sure, I have some coding experience, I can perhaps help out in that area. I'm just not familiar with the LTSP architecture so I'll have lot's questions along way, naturally. :)
14:24
<alkisg>
For example, if you can troubleshoot the vt issue, and find a proper solution (not a workaround), filing a bug report with a patch would help a lot
14:25
<octoquad>
sure, I've tried a few things already for that. I will keep digging and provide a patch.
14:25
<alkisg>
That's what taking most of the ltsp development time, finding correct solutions to such issues
14:26
<octoquad>
For instance, the gnome-initial-setup is a problem in 18.04, I have LTSP plugin I use for disabling that by inserting the config option in /etc/gdm3/custom.conf
14:26
<alkisg>
I've a similar plugin that removes ubuntu-mate here :)
14:26
<octoquad>
Wayland is also a problem, lot's of fail whales. So I have another LTSP plugin which disables Wayland in /etc/gdm3/custom.conf
14:26
<alkisg>
*ubuntu-mate-welcome
14:27
<octoquad>
ah
14:27
lol
14:27
<alkisg>
I'm rewritting most of the server configuration code as `ltsp-config` plugins
14:27
So e.g. `ltsp-config gnome --disable-initial-setup` or such
14:28
<octoquad>
Oh interesting, that is actually pretty neat, perhaps I can contribute on the GNOME side.
14:29
Do you have any developer documentation up? I might be also keen to update documentation around the project. For instance syslog setup doesn't work anymore, but I did manage to get rsyslog running with 18.04 and fat clients.
14:31
<alkisg>
You can go to wiki.ltsp.org and edit whatever you feel is wrong
14:31
(or missing)
14:31
<octoquad>
thanks
14:31
<alkisg>
You too
14:33
<octoquad>
thanks so much for the feedback, I'll pop in again during week.
14:33
ciao
14:33octoquad has left IRC (octoquad!~octoquad@197.231.147.54, Quit: See you in the future)
16:43lucas__ has left IRC (lucas__!~lucas@177-185-141-105.isotelco.net.br, Quit: Leaving)
16:43lucascastro has joined IRC (lucascastro!~lucas@177-185-141-105.isotelco.net.br)
16:54aheyde has joined IRC (aheyde!~aheyde@2001:44b8:311a:af05:69b8:942d:32e5:66a3)
17:21adrianor1 has joined IRC (adrianor1!~adrianorg@187.113.219.239)
17:24adrianorg has left IRC (adrianorg!~adrianorg@177.134.57.237, Ping timeout: 240 seconds)
19:42ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
22:10adrianor1 is now known as adrianorg
22:59lucas_ has joined IRC (lucas_!~lucas@177-185-141-105.isotelco.net.br)
22:59lucascastro has left IRC (lucascastro!~lucas@177-185-141-105.isotelco.net.br, Read error: Connection reset by peer)
23:36GodFather has joined IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net)
23:42GodFather has left IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net, Ping timeout: 250 seconds)