Re: [Dorset] Jitsi Security
On Friday, 10 April 2020 16:31:49 BST Patrick Wigmore wrote: > I'm using KMail too, but I didn't realise it had this feature. > > It looks like it does it if you edit the mail in rich text mode and > then convert it to plain text with markup. > > Normally I just edit in plain text mode directly, so I never encounter > it. Ah! I thought I always edited in plain text, but I've just noticed the button in the Toolbar is highlighted. I've just copied and pasted the following URL straight from Chromium's URL bar to test your point: https://ark.intel.com/content/www/us/en/ark.html#@Processors If this works, I must remember to only turn Rich Text on when I need it and definitely not when I'm writing to this list. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2020-05-05 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] BOINC CPU Utilisation
On Friday, 10 April 2020 16:17:08 BST Ralph Corderoy wrote: > I don't see a mention of ‘thread’ in either of those screenshots. :-) True, but the CPU has four cores each supporting two 'threads' according to the datasheet. (This is written as 'four cores and 8 threads.) It doesn't help that the System Monitor shows 8 CPUs. ;-( However, your explanation does clear up a few things for me about what a thread is in hardware terms. Although I never knew the detail that you've provided I could understand the concept of a software thread; my problem has always been how that related to a hardware thread. > If a core duplicates everything needed to run code then two cores allow > the programs multiplexed onto them to run entirely independently; > neither interferes with the other. But that's more expensive than a > cheaper short cut that Intel named HyperThreading. A puffed-up name for > a cut-down feature. They realised that two duplicate cores often have > different parts of their circuitry active at the same time, e.g. one > might be loading a byte from RAM whilst the other is working out > ‘a=b*c+d’. Thus some of the bits of circuitry can be shared between the > two cores as long as they're ‘gated’ at the entrance and exit so only > one of the cores is using the shared part at the same time; like a > single-line stretch of railway. So why am I not surprised that it's all the fault of the Marketeers? -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2020-05-05 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Jitsi Security
On Fri, 10 Apr 2020 11:44:03 +0100, Terry Coles wrote: > > What appends the ‘[1]’ at the end of the URL? The terminal here > > thinks it's part of it, as shown by the underline drawn on hover, > > and passes it to The Grauniad. > > That's KMail That always catches me out! (The trick is to remember to use the URL in the footer, rather than the one inline.) I'm using KMail too, but I didn't realise it had this feature. It looks like it does it if you edit the mail in rich text mode and then convert it to plain text with markup. Normally I just edit in plain text mode directly, so I never encounter it. For a hyperlink of the text 'example' to the url 'https:// example.com/', the result is example[1]. However, if you insert the URL as both the 'Link text' and the 'Link URL', you will instead get https://example.com/[1], which causes the problem. (I notice it will only refer the first instance of a given URL to the footnote, annotating subsequent instances with _underline_ markup instead, so this email of mine, containing two references to the same footnote, could only have been written some edits in plain text mode.) [1] https://example.com/ -- Next meeting: Online, Jitsi, Tuesday, 2020-05-05 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] BOINC CPU Utilisation
Hi Terry, > > flipping back and forth between the two at a regular equal interval > > will be an arithmetic mean near the 75% target? > > Well yes, but the CPU History tab is showing each core at 100% for > ~75% of the time. I think I'm still trying to get my head around the > difference between CPU threads and program threads. > > I think that what you are saying that the Process Table is showing CPU > percentage for the whole processor, (eg all cores and all hardware > threads) with the % consumed by each process It looks like it, especially if they sum to about 100% when the machine can't do any more labour. > whereas the History tab is showing the percentages for each individual > hardware thread. For each individual CPU, yes. > If so, it would have been better if the software guys or the hardware > guys (whoever came last) had picked some other name for the feature > that they wanted to describe. I don't see a mention of ‘thread’ in either of those screenshots. :-) A thread of execution is similar to when you ‘lose the thread’ of a conversation or plot-line. The thread is the path taken and the context needed to track progress so far and what you've learnt along the way. Similar to when you're wandering around an unfamiliar town, turn a corner, and realise you've been there before. Going back to a simple CPU like the 6502 in the BBC Micro, it tracked one thread of execution, ignoring ‘interrupts’. - What results it had already worked out, stored in registers in the register file. - Where it was in the program's machine instructions, stored in the Program Counter, PC, again in the register file. - Where it had been and needed to return to by putting future PC values on a ‘stack’ in RAM. - A Stack Pointer, tracking how much of the stack had been used, alongside the registers and PC. If you want the 6502 to stop doing one task and switch to another then it needs to make a note of where it had got to so far, its context, and start afresh for the new second task. That's a ‘context switch’. After a while, it can stash its workings out for task Ⅱ and context-switch back to task Ⅰ. It's now tracking two threads of execution, but only one is running at a time. The 6502 has one context stored in hardware in the register file. It requires software to switch contexts; to ‘multiplex’ multiple contexts, or threads of execution, onto the one hardware context. That software copies the hardware context into task Ⅰ's RAM and then sets the hardware context to the saved context from task Ⅱ's RAM. So you can have many software threads; they're just data. A Unix process is a software thread plus some more operating-system context, e.g. what files the process has open. Build a CPU that duplicates the register file so there's now two and the hardware can track two contexts at once. Now two program counters can step through machine instructions in parallel if enough of the other CPU circuitry is also duplicated. Two of the many software threads can be multiplex onto the two hardware threads at the same time. Each hardware thread is part of a CPU core. If a core duplicates everything needed to run code then two cores allow the programs multiplexed onto them to run entirely independently; neither interferes with the other. But that's more expensive than a cheaper short cut that Intel named HyperThreading. A puffed-up name for a cut-down feature. They realised that two duplicate cores often have different parts of their circuitry active at the same time, e.g. one might be loading a byte from RAM whilst the other is working out ‘a=b*c+d’. Thus some of the bits of circuitry can be shared between the two cores as long as they're ‘gated’ at the entrance and exit so only one of the cores is using the shared part at the same time; like a single-line stretch of railway. A lot of the time this gives double the performance of a single core with less than double the manufacturing cost. However, if the workloads on both cores often want to do the same shared thing, a=b*c+d, then each often holds the other up and the speed cuts back to some low multiple of one core rather than two cores. And bigger CPUs again might have ‘four cores with HyperThreading’ which means each of the four has a partially duplicated circuit allowing threads of execution to be tracked and potentially all running at once, as long as they're not waiting for those single bits of train track. The ideal for some users is no HyperThreading, just true duplicates cores within a CPU, and perhaps more than one such CPU. This allows them to better characterise the performance they'll obtain because there's no gated shared circuitry that has one execution thread delay another. That might need more than one read; it's a linear dump of an explanation rather than something that's had refined editing. -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2020-05-05 20:00 Check to whom you are replying Meetings, mailing list
Re: [Dorset] Jitsi Security
On Friday, 10 April 2020 11:37:01 BST Ralph Corderoy wrote: > Something they don't mention is the source code for the central server > is available and can be run on your own equipment instead of relying on > their hosted server. Given the media is encrypted to and from that > server, but decrypted within it, that might be of interest to some. One > of the DLUG #dorset IRC members got it running to play around with. This is the Guardian :-) I think it's a major step forward that they cited Open Source as a plus and not a cancer :-) > Also, if only two parties are in a room then the two Jitsi's end up > sending packets directly to each other most of the time, with the server > only being involved during the set-up. This can be observed by the IP > addresses/hostname shown with tcpdump(1). Yes that came up in the Meeting. > What appends the ‘[1]’ at the end of the URL? The terminal here thinks > it's part of it, as shown by the underline drawn on hover, and passes it > to The Grauniad. That's KMail, the '[1]' is like a document reference with the real address underneath the Sig. It caused mega problems when it first came out, but most people have got used to it now. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2020-05-05 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Jitsi Security
Hi Terry, > https://www.theguardian.com/technology/2020/apr/08/zoom-privacy-video-chat-alternatives[1] > In particular they say [Jitsi] is a 'more secure alternative to Zoom'. Something they don't mention is the source code for the central server is available and can be run on your own equipment instead of relying on their hosted server. Given the media is encrypted to and from that server, but decrypted within it, that might be of interest to some. One of the DLUG #dorset IRC members got it running to play around with. Also, if only two parties are in a room then the two Jitsi's end up sending packets directly to each other most of the time, with the server only being involved during the set-up. This can be observed by the IP addresses/hostname shown with tcpdump(1). What appends the ‘[1]’ at the end of the URL? The terminal here thinks it's part of it, as shown by the underline drawn on hover, and passes it to The Grauniad. -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2020-05-05 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
[Dorset] Jitsi Security
Hi, At the meeting we briefly touched on security and privacy concerns with regard to Jitsi as compared to Zoom and the like. Although I wouldn't normally search the Guardian's output for Tech stuff, this article gives it a good write-up. https://www.theguardian.com/technology/2020/apr/08/zoom-privacy-video-chat-alternatives[1] In particular they say it is a 'more secure alternative to Zoom'. -- Terry Coles [1] https://www.theguardian.com/technology/2020/apr/08/zoom-privacy-video-chat-alternatives -- Next meeting: Online, Jitsi, Tuesday, 2020-05-05 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
