IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 13 May 2018 (all times are UTC)
| 01:07 | lucas__ has joined IRC (lucas__!~lucas@177-185-141-105.isotelco.net.br) | |
| 01:07 | lucas_ has left IRC (lucas_!~lucas@177-185-141-105.isotelco.net.br, Read error: Connection reset by peer) | |
| 02:50 | aheyde 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:16 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 04:27 | alkisg_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:14 | alkisg_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:01 | TheBoyd has left IRC (TheBoyd!~TheBoyd@2605:a601:652:9500:892e:e98a:7311:2174, Quit: Leaving.) | |
| 07:09 | TheBoyd 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:20 | eemeli 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:27 | eemeli 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:50 | Statler|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:18 | markit 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:25 | ricotz has joined IRC (ricotz!~ricotz@p5B2A87F4.dip0.t-ipconnect.de) | |
| 10:25 | ricotz 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:05 | edgar^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:28 | Statler|Home has left IRC (Statler|Home!~Georg@p5489740C.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 13:00 | GodFather has left IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net, Ping timeout: 240 seconds) | |
| 13:13 | GodFather has joined IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net) | |
| 13:15 | aheyde has left IRC (aheyde!~aheyde@2001:44b8:311a:af05:d0a4:355f:fe97:6575, Remote host closed the connection) | |
| 13:27 | markit has left IRC (markit!~marco@mail.ammdomus.it, ) | |
| 13:34 | octoquad 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:48 | GodFather 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:33 | octoquad has left IRC (octoquad!~octoquad@197.231.147.54, Quit: See you in the future) | |
| 16:43 | lucas__ has left IRC (lucas__!~lucas@177-185-141-105.isotelco.net.br, Quit: Leaving) | |
| 16:43 | lucascastro has joined IRC (lucascastro!~lucas@177-185-141-105.isotelco.net.br) | |
| 16:54 | aheyde has joined IRC (aheyde!~aheyde@2001:44b8:311a:af05:69b8:942d:32e5:66a3) | |
| 17:21 | adrianor1 has joined IRC (adrianor1!~adrianorg@187.113.219.239) | |
| 17:24 | adrianorg has left IRC (adrianorg!~adrianorg@177.134.57.237, Ping timeout: 240 seconds) | |
| 19:42 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 22:10 | adrianor1 is now known as adrianorg | |
| 22:59 | lucas_ has joined IRC (lucas_!~lucas@177-185-141-105.isotelco.net.br) | |
| 22:59 | lucascastro has left IRC (lucascastro!~lucas@177-185-141-105.isotelco.net.br, Read error: Connection reset by peer) | |
| 23:36 | GodFather has joined IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net) | |
| 23:42 | GodFather has left IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net, Ping timeout: 250 seconds) | |