Archived threads in /g/ - Technology - 4388. page

>>58932000
/thread

File: 1486386802373.jpg (161KB, 1446x1462px) Image search: [Google]

161KB, 1446x1462px

>>58932007
kek

7zip, RarZilla, MBAM

python

File: renpy_logo.png (60KB, 200x307px) Image search: [Google]

60KB, 200x307px

python

>>58931561
>>58931575
>>58931619
me

>>58930984
you're not thinking in large enough terms, when you get into the hundreds and thousands of computers and printers, all interconnected with a server there's just too much for unmanaged switches to handle and too much at stake for a plug it in and hope it works approach

>>58930984
>Why would you need a managed switch in a business? What is wrong with just plugging shit in and hope it works?
Because it's a huge hassle when shit doesn't work.

Managed switch allow automatic configuration and organisation.

why do we need car mechanics? can't we just hop in and hope it never breaks?

why do we need doctors? can't we just live and hope nothing goes wrong?

You write your text in a text editor. That's what they are made for. LaTeX is only for turning the finished text into a pretty-looking .pdf file.

>>58929481
I use LaTeX for longer documents, yes.

What specifically do you find horrific about it?

>>58929534
Not OP and a LaTeX user but the amount of packages you need to load in to make it usable isn't great. Syntax is hit and miss.

>>58929325
http://rms.sexy/

Pick one, and only one.

Stallman gives definite statements in indefinite times.

>>58929325
where to cop?

>>58928150
first for shit thread

>>58928150
>Xiaomi releases a phone with female repellent >>58922451
I laffed.

unban zambz

>>58927560
Resign.

kill 4chan/le reddit/la facebook

>>58927563
this

>>58927553
2 32 gig rams btw, did not notice it was missing

Someone to end my life

>>58927553
AMD Ryzen

>>58927341
You might argue that the kernel could provide some form of protection against this, for example offering an API that provides the physical memory regions that are valid for the device alone. The issue, however, is that where in memory device are mapped is a completely arbitrary process and done solely at the discression of the BIOS. In other words, you'd end up with an extremely bloated API that does a bunch of redundant checking in order not to expose physical address space to user-space. This would violate the very premise for running a microkernel in itself, not to mention that you'd be exporting a bunch of functionality such as pinning pages, requesting DMA buffers at certain ranges with such and such alignment, to user-space while still having to do all the checks in kernel. If you think syscalls are a bad idea and very monolithic, imagine this monstrosity of an API.

Of course, this only addresses the issue of a driver having access to physical address space. Then there's also the issue of DMA and the device itself. When a driver does DMA, it typically requests the kernel for a continuous memory region which the device is able to reach (some devices, such as Nvidia GPUs only have 30 address bits, meaning that they can't address the entire 64-bit address space). The driver then passes the address of this range to the device (writing it into a register using MMIO) and the device will then either read or write directly to RAM without involving the CPU. In other words, Direct Memory Access (DMA).

2 / 4

>>58927351
Myth 2: IOMMUs solve everything

The problem though, is that the driver can pass along ANY physical address and make the device read or write into arbitrary memory locations (again, for example where the kernel resides). Of course, you'd might be thinking right now that this is where IOMMUs come in, and you're quite right.

In addition to eliminating the need for bounce buffers (the case mentioned above where the Nvidia GPU need to address something above 30-bit address), IOMMU can also provide address isolation by grouping devices into so-called domains. This prevents a driver from flushing data into random physical addresses. HOWEVER, the problem again is that setting these up are usually the task of the device driver. Exposing IOMMU access to user-space is a bad idea, so you'd end up incorporating this into the horrendously bloated API mentioned above.

This of course assumes that there is an IOMMU available in the first case, something architectures other than x86 usually don't have. There's also the issue with PCIe P2P, enabling the IOMMU means that every TLP (aka memory operation) is forwarded to the root complex instead of just taking the shortest path. A network card reading from a disk would experience a serious performance degradation. There is stuff like ATS but they are highly vendor specific and an AMD implementation of ATS is not respected by Intel's VT-d for example. In additon, only a minority of devices actually support ATS. Nvidia GPUs certainly don't.

3 / 4

>>58927356
Myth 3: The performance penalty of running in user-space is negligible

As I mentioned above, P2P performance is kill if you use an IOMMU. However, the biggest performance killer is the cost of context switch.

First of all, running in user-space means that your driver is subject to the scheduler and in risk of having it's memory swapped out. Of course, you could solve this by giving higher priorities to the driver as well as pinning its memory in RAM, but then you again have the situation where there is no real separation between user-space and kernel-space. The Linux kernel also runs in virtual address space and its memory is just always part of the first 1 GB of memory and protected using the hardware page protections. So in effect you blur out the differences between kernel-space and user-space and you gain none of the "benefits" of running in user-space.

The real issue here, however, is that you'd need some sort of mechanism to disable interrupts (and thus preemption) from user-space, because sometimes the device driver might do something that requires atomicity and can't be interrupted by the scheduler. So add this functionality to the already bloated driver API and in addition further blur out the hard separation between kernel-space and user-space.

Secondly, there's also the issue of device initiated interrupts. Imagine a Gigabit ethernet network controller generating an interrupt for every received packet. Normally, interrupt routines are short and do little stuff. For user-space drivers, however, you'd need to context switch back into user-space and then run some routine in user-space while at the same time providing deadline guarantees and blocking guarantees.

4 / 4

literally just bought one today. it finally dropped enough in price to fit my rule of never paying more than $300 for a phone.

File: Smartisan-M1L-hands-on-GSM-Insider-1.jpg (58KB, 600x450px) Image search: [Google]

58KB, 600x450px

Yes, the Smartisan M1L.

>>58927331

Huawei P8 Lite

Transmission

Deluge, Transmission or rtorrent.

"why should I pay for other people's hard work I will just get it for free" freetard ideology... Nothing to do with freedom, everything to do with gibsmedat

>>58926002
UNIX/Linux filesystem structure is outdated as fuck

>>58926002
I like its design but I left it when I accepted that I could do the whole workspace-centric DE thing with basically any other environment, using less resources.

File: 1485929424397.jpg (33KB, 506x600px) Image search: [Google]

33KB, 506x600px

>>58926002
Bloated, no options, wasting space with thicc top bar, inane depediences (systemd).

>>58925594
/thread

I think you mean
>windows desktop
>windows laptop/tablet
>linux server
>android phone

>linux everything
This is literally the best

/thread

>>58925471
When it'll be able to run proper, industry standard software without the need of 3rd party garbage, also when it won't require up to 1h to fix something that can be fixed on Windows/macOS in under a minute.
tl;dr: never

>>58925492
>>58925540

Windows has been beaten in the ML space and macOS isn't even on the radar. When ML comes to consumers, Windows will die.

>>58925540
>use linux
>search for solution
>find it immediately

>use windows
>search for solution
>have to go through a lot of threads from 2005 only to find they never fixed their problem or the classic "thanks guy i fixed it you can close the thread now"

Mac OSX

>>58924203
name checks out.
>>58924198
That time isn't wasted unless you go back to ubangoo my man. You did get half an OS working on your own, try it for a month. I liked the arch base but there's just something comfier about apt

File: 1460518646960.png (55KB, 1301x326px) Image search: [Google]

55KB, 1301x326px

>>58924198
As you can see it won't work OOTB, which can help you to get used to the Unix learning curve. Ubuntu is fine too.