/tech/ - Technology★

I'll wait for bspwc

>>956539 (OP)

i just hope they wont make it dependent on systemd

>>956570

Don't worry!

Your favorite desktop will feature Pipewire, another innovative software brought to you by RedHat.

Pipewire will feature a direct link to SYSTEMD in order to manage all video and audio.

Using SYSTEMD it will be possible to EASILY enable or disable video rendering or audio using the fantastic SYSTEMD tools.

I've not used wayland but they've had a terrible time delivering what should have been a relatively simple component so I suspect it's another btrfs-tier disaster.

It should be easy to make today as all the crazy shit and 'exercise for the reader' parts of the graphics stack are gone. We no longer are having to write custom versions of bresenham's algorithm that split things across 4 bitplanes just to draw a line or support wacky cards with hardware accelerated subregion scrolling in 2D. The remaining hard part, network support, they dropped. I don't know if they did anything with the font server but that's an archaic concept anyway.

>>956576

If we just stopped complaining about poetteringware for a moment and instead utilized that wasted time on contributing to Devuan, maybe, just maybe, Devuan could become a fully competitive distribution against Debian. I'm just saying.

>>956588

What's the point of Devuan other than butthurt containment? Debian still supports sysvinit and it works fine even with GNOME 3 and Chromium.

>>956588

Devuan is made by SJWs, do not use.

>>956599

Most free software projects are made by SJWs. Fork the code and slap a nazi icon on it if this triggers you so much.

>>956599

So? All SJW's are white.

>can't run wayland over a network

nu-X is fucking aids

>>956617

There's no reason why you cannot run an X server on top of Wayland.

https://wayland.freedesktop.org/xserver.html

>>956590

Because just about everything in Debian repos is built to expect systemD. It got to the point where it was easier to fork the entire distro than it was to maintain a systemd-free repo. This is why systemD is such a cancer.

>>956599

proof?

>>956625

What kind of ridiculous bullshit is replacing X with wayland only to have to run X on wayland?

Use it for a small setup with sway, can't really complain but on the other hand don't see why you should switch from X

>>956630

>Because just about everything in Debian repos is built to expect systemD

You niggers keep saying that yet when I try it everything still works fine on Debian with sysvinit. And I can switch between the two at will with a GNOME 3 desktop without some sort of massive cascade that uninstalls half the system as Devuan shills claim. Here, look:

anon@anon:~$ sudo apt-get install sysvinit-core
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  cgmanager initscripts insserv libcgmanager0 libnih-dbus1 libnih1 startpar systemd-shim sysv-rc
Suggested packages:
  bootchart2 pm-utils bum bootlogd
The following packages will be REMOVED:
  systemd-sysv
The following NEW packages will be installed:
  cgmanager initscripts insserv libcgmanager0 libnih-dbus1 libnih1 startpar systemd-shim sysv-rc sysvinit-core
0 upgraded, 10 newly installed, 1 to remove and 0 not upgraded.
Need to get 738 kB of archives.
After this operation, 1,634 kB of additional disk space will be used.
Do you want to continue? [Y/n]

All I have to do is add /etc/inittab and I'm good to go. So what, SPECIFICALLY, is Devuan providing that I don't already get with stock Debian?

>>956641

You don't understand what is the purpose of Wayland. Protip: Wayland is developed by the same people who maintain X.org who understand exactly how X11 is used today in actual practice.

>>956647

>Wayland is developed by the same people who maintain X.org

That's not exactly inspiring confidence.

>>956650

Is there a better authority on the X11 protocol than the X.org developers who spend their expertise trolling through the reference implementation of X11?

>>956586

I've never understood why FOSS has so much trouble with graphics and sound.

And file systems.

And init systems.

And efficient desktop IPC

>>956651

They're shills because they make statements like "just about everything in Debian repos is built to expect systemD" which is obviously not true.

>pozzed as default

A justification for an entire distro being that they didn't like one default is pure autism. Debian doesn't have to be installed with systemd. I run a multistrap build for work that installs stretch with sysvinit. WSL also doesn't use systemd on stretch.

>I run Gentoo but I can't change a default

>>956671

"They" didn't make that statement, I made that statement because that statement is true.

>A justification for an entire distro being that they didn't like one default is pure autism.

Maybe, why do you care? Because those with autism do the majority of the work perhaps? You seem to have an autistic need to defend your beloved distro

>Debian doesn't have to be installed with systemd.

This is true if you want to spend all that time with configuration and marking systemd in apt so it doesn't pull it when you upgrade or pull something that depends on it by default (which is nearly everything). Why do through the trouble of doing it yourself when an entire community maintains a distro that does it for you? If you don't want systemd there is no reason to use a distro that uses it by default.

>I run a multistrap build for work that installs stretch with sysvinit. WSL also doesn't use systemd on stretch.

Good for you, you could avoid all that work by just using a distro that does the same exact thing by default. You're the one with autism.

>I run Gentoo but I can't change a default

I can change the default. I'm just not a retard that uses a pozzed distro then yells at other people that forked it and made their own thing.

Again you sound like a butthurt faggot.

>>956671

>A justification for an entire distro being that they didn't like one default is pure autism.

Uhh, that's the reason why 90% of all other distros exist, especially debian/ubuntu based.

I don't get why people are so butthurt about devuan, it's just like every other debian based distros with different defaults. Why don't you get mad about ubuntu instead?

>>956590

>guys, debian supports sysvinit

t. someone who hasn't tried to run Debian without systemd

Every time.

>>956559

Because every program regardless of the user they are run as can read every key press every mouse click and every pixel of your screen. xorg is total shit.

fuck wayland and fuck systemd

>>956681

>being so butthurt you go this far to defend systemd and Debian

>>956684

>it's poz even if it's not running and not pid 1

That's just autism, anon. You'd throw a tantrum at my code too as I build optional systemd support for systems that run it and build-depend on libsystemd-dev for sd-daemon.h. Devuan would fork my package for that even though I don't require systemd. Programmers treat their distro as a joke because it is.

>If you remove systemd meaning you purge it from the entire system it breaks everything

And yet I literally have no trace of systemd on my embedded builds and they somehow still work. It's almost like this is the outcome that Debian voted on. Huh.

>says he uses Debian for the "fast security updates"

What would a gentoo user even know about security updates. You don't even have any, you have new versions with new bugs. Rolling distro rolling into a ditch and catching fire.

>not using kernel mode setting and buffer management directly

casual

>>956539 (OP)

>replacement for dwm

Nope.

>>956682

>systemd and wayland are comparable

look systemd is a bloated piece of shit but wayland actually solves a shit ton of problems X has.

X11 IS NOT NETWORK TRANPARENT IN IT'S CURRENT USAGE

https://youtu.be/GWQh_DmDLKQ?t=1113

>>956675

In every distros default setup any program you run can read, delete, or alter any file within your home directory.

Wayland is fundamentally flawed, due to horrible design decisions, which are completely unnecessary. it's impossible for something running over Wayland to perform as well as something running over X can. Fixing this would require breaking everything.

>>956764

What flaw?

>>956764

>In every distros default setup any program you run can read, delete, or alter any file within your home directory.

Absolutely not true. Basic linux permissions and group / user support prevent this. Linux programs can only edit your home directory if they specifically have access.

Xorg is not like that at all. Any program under any user can do anything.

>it's impossible for something running over Wayland to perform as well as something running over X can.

Absolutely incorrect. Wayland has far far less overhead than x.

I'm not switching until someone ports xmemead

>>956975

>not how every modern GUI works

Except wayland I guess, which can't do streaming in an era defined by streaming. Loonix, always a decade late.

It's a necessary replacement. I am waiting for sway 1.0.

>>956975

>oh no I'm being key logged by my key logging program

web devs in charge of handling input

>>957012

>oh no my files are being deleted by my file deleting program

yeah I agree anon why even have file permissions. Everything should be totally unified. Security is totally retarded.

>>957021

File permissions saves /etc/ but not any of the actually valuable user files.

Yeah you are running X on a totally secure server. Totally.

>>957031

>File permissions saves /etc/ but not any of the actually valuable user files.

bullshit file permissions solve tons of things. You run your webserver as its own user. When it fucks up its isolated.

>Yeah you are running X on a totally secure server. Totally.

who are you even talking to i'm the one that hates X

>>956975

>>957012

>>957021

>oh no my program can do things

https://lubuntu.me/lubuntu-development-newsletter-9/

>Lubuntu will be switching to Wayland by default for 20.10.

>We are going to do this by porting Openbox to use the Mir display server, Drew DeVault’s QtLayerShell, and other associated bits.

>>957042

I'm talking to 1/100000 user who runs X with security in mind.

Wayland has no features. Look at OP he says it would be about 10k loc to reach the same as 50 loc for tinywm under X.

This is why nobody uses wayland.

Even worse is warnings like termbox where it looks OK then suddenly the dev is like fuck memory use Go instead. Nobody will port shit. We will end up with SDL terminals.

Let's say I have two PCs set up with Wayland. I want to SSH from one into the other and remotely run a GUI program. How do I do it?

>>957166

Using the Weston RDP compositor.

>>956975

This is how every OS and distro have worked for the last 30 years. Whatever "solution" wayland has is probably yet another meme. For starters either all code would have to run as separate users or just all code is some interpreted language with no privileges. Linux isn't even designed for multi user security (aside that it LARPs about it by having file privileges and such). Ironically, all the programs will indeed still have access to /dev/ as well as

>/proc/

>/sys/

>/mount/

>stuff like the wall command

>be able to read command lines of programs

etc

If you open a python or haskell shell in a folder that's not owned by you, it will execute code left in that folder (for example .ghci). If you chown a file in a folder that's not owned by you, it could be replaced with a link to /etc/passwd right before chown runs. Your OS is shit nigger and there's no saving it. I highly doubt Wayland fixes these problems and the other 9001 of them. Do you even know how file permissions in Linux work? Almost nobody does, despite claims that they are simple.

>>956891

You literally can't do anything in Linux without compromising multi user security. X11 of course just makes the problem far worse.

>>957166

Install the Weston Xserver.

>>957167

How do more lines of code translate to LESS modularity?

>>957378

inb4 it uses triple buffering or double buffering (starts rendering after vblank). enjoy your >=16.66ms input lag and rsi

>>957438

Sucks, but it sweeps every other lag issue completely under the rug forever, and if combined with a better refresh rate (>120Hz) it wouldn't even increase latency.

>>957157

Wow, they're actually porting OpenBox to Wayland.

Everybody used to say that simple X11 window managers couldn't be ported to Wayland because it has to be a compositor as well, and therefore will mean blowing them up in size by at least an order of magnitude.

>>957223

>what is namespacing

Basic features to prevent shit like this have been around since 2002 you retard. X11 has to go.

>>956665

That's what zero market pressure gives you.

>>957511

No xorg on system+openbox+lxqt+sway in windowed mode = super comfy. Just needs a non-pozzed wayland only browser for maximum userland security. Port more emulators to use pure qt and you can get emulators with no xorg dependencies in the future. VLC already works without Xorg. There's pure wayland/no xorg music players. Libreoffice works in qt/wayland only mode but doesn't have options to remove xorg yet?. There's a single qt/pure wayland archive manager. Gimp and blender are fine in pure wayland using gtk3 howbeit shit interface. Wine works in pure wayland, but no 3d acceleration/vidya without X. And that's all I can think you could want that's not just command line only stuff or propietary software.

>>957223

Wayland isn't a solution to x11's problems, it is a restart from scratch using linux kernel specific interfaces to make common agreed upon solutions to certain usages of the framebuffer and input devices in userspace. It is designed around single user security and not needing root for anything if you use permissions correctly. The new code base lets it be smaller and more easily auditable compared to x11's cruft you have to go through just to get stuff to work, letalone be secure.

>>957536

>comfy

>muh bing bing wahoos

>security, security, security

This better be a joke.

>>957545

Security is no joke. And what's wrong with getting one's bing bing bing wahoos? Everybody needs a break once and while.

>>957350

That's one way to go, but I would recommend Weston-RDP, it's a much more efficient protocol.

>>956588

As if a bunch of 8chan lusers who do nothing but cry all day about 'poetteringware' will ever do anything as substantial as creating and using their own user space.

Cattle isn't meant to be taken seriously when they cry about the state of affairs. They're meant to be led and use whatever scraps we give them without complaining.

>>957536

Wayland is shit. Can't even change the brightness on my fucking laptop after 3 hours of scouring documentation and the internet.

>>956590

I used to repeat this. Any time someone complained about systemd I parroted "Debian works without systemd!"

No it doesn't. It technically does, but half the system depends on it.

>>957707

I just installed sysvinit-core, rebooted, and purged systemd. At what point does "half the system" stop working? Does it take time? Should I check back tomorrow?

>>957720

Way to be a n00b

apt will pull system-d without making configurations and shit will break down the road. Devuan modifies any packages that conflict with systemd. You'll end up wasting hours of your time configuring things and always need to change shit. Devuan has a reason to exist so you can suck on mah ballsak

>>957722

>apt will pull system-d without making configurations

Moving goalposts. What happened to your claim that "half the system" depends on it? As soon as I try it and show that's bullshit you just move on to the next piece of bullshit without saying a word.

But let's talk about this new bullshit. How is apt going to magically pull in systemd when "update" will hold back packages with dependencies that require removals? How are conflicting dependencies even going to get added to a stable release?

Why can't Devuan supporters ever give specific examples as to why their distro exists? It's always this tin foil hat shit about what might happen in the future.

>>957724

Devuan's shit anyways. Artix is the way to go in my opinion, and don't give me none of that "it's the same shit" argument, they clearly have different target userbases that happen to overlap in the "No systemd" department

>>957510

I've tried double buffered vsync (render after vblank) on 120Hz which gives 8.33ms input latency, and it's still a deal breaker.

>Sucks, but it sweeps every other lag issue completely under the rug forever

o-okay

>>957699

Assuming you use intel here. Just open /sys/class/backlight/intel_backlight/brightness with your text editor of choice. I don't use wayland since it's shit, but I highly doubt that won't work.

>>956891

>Absolutely not true.

Try writting "rm -rf ~/*" in a text file, chmod +x, and running it from a terminal. I absolutely assure you it will happily proceed to work on pretty much any distros defaults.

>Absolutely incorrect. Wayland has far far less overhead than x.

Wayland is a lot smaller in regards to code size, but that doesn't it has less overhead. Graphics have to jump through a very long series of hoops in order to get rendered on screen, and it has very significant effects on performance. If you're already using compositing on X the difference is not as significant, though it's still there.

>>957831

>Devuan exists because Debian didn't want xlennart in the repo!

Good joke.

>All this poettering-ware drama

Thank god devuan and mx-linux exist.

>>957699

Use acpilight you faggot. It might use the name "xbacklight" in command but it is completely independent of xorg and wayland. You can change brightness from the tty with it.

>>957883

Mir is going to be a Wayland compositor now, and may just make Wayland great by being a target for small X11 window managers >>957511

>>957887

Shit, meant to point out this post >>957157

>>957884

Oh and you think you're so smart asshat? I've tried every utility under the sun asshat, fiddled around in any directory related to brightness. Only thing I didn't do yet is look at xrandr's code you goddamned incompetent fuck.

>>957805

Can't find the /intel_backlight directory specifically but I tried modifying any brightness related values in /sys/class/backlight/acpi_backlight0 (or named something similarly) and nothing works. My last resort is checking out xrandr's code in my spare time, thanks for the help though. Appreciate it.

>>957805

>Try writting "rm -rf ~/*" in a text file, chmod +x, and running it from a terminal.

Yes faggot if you run the program as a user with permissions to delete your files of course it can. Linux allows you to securely configure users that cant. This one must have gone over your head as a windows user.

>>957159

>fuck memory, us GO instead

Golang? Never had memory issues using Go. What are you complaining about?

>>957933

>Linux allows you to securely configure users that cant.

Yes, you're fully right, there's a very good reason I said by pretty much any distros defaults.

>>957923

It might not be symlinked by default, tried searching from / for any folder named intel_backlight? From what I'm aware it's a very standard feature and anything intel should provide it, granted it's always worked for me, so I've never had much reason to look closely into it.

>>958045

>there's a very good reason I said by pretty much any distros defaults.

It's a fucking retarded statement then.

>A user can delete their own home directory

no shit

>>957938

Isn't a Hello World in go a megabyte of code and a big pile of ram?

>>958059

Languages with a runtime system will always use more RAM compared to those without. That being said, no.

>>958063

>no

anon@anon:~$ cat foo.go
package main
import "fmt"
func main() {
  fmt.Println("Hello, Google turned Rob Pike into a tranny")
}
anon@anon:~$ go build foo.go
anon@anon:~$ ls -alt foo
-rwxr-xr-x 1 anon anon 1633717 Aug 19 18:05 foo
anon@anon:~$ strip foo
anon@anon:~$ ls -alt foo
-rwxr-xr-x 1 anon anon 1020296 Aug 19 18:08 foo
anon@anon:~$ /usr/bin/time --verbose ./foo
Hello, Google turned Rob Pike into a tranny
...
        Maximum resident set size (kbytes): 932
        Minor (reclaiming a frame) page faults: 254

wew?

>>958073

932 kB for a hello world? That seems excessive.

>>958079

It is. The same thing in assembly,

anon@anon:~$ ls -alt foo
-rwxr-xr-x 1 anon anon 496 Aug 19 18:48 foo
anon@anon:~$ /usr/bin/time --verbose ./foo
Hello, Google turned Rob Pike into a tranny
...
        Maximum resident set size (kbytes): 156
        Minor (reclaiming a frame) page faults: 22

I could tune away some of that RSS and strip off more ELF shit but it's good to show how much of the bloat is from the OS and not the language.

>>958086

Forgot code,

anon@anon:~$ objdump --disassemble foo

foo:     file format elf64-x86-64


Disassembly of section .text:

0000000000400080 <.text>:
  400080:       b8 01 00 00 00          mov    $0x1,%eax
  400085:       bf 01 00 00 00          mov    $0x1,%edi
  40008a:       48 be a8 00 40 00 00    movabs $0x4000a8,%rsi
  400091:       00 00 00
  400094:       ba 2c 00 00 00          mov    $0x2c,%edx
  400099:       0f 05                   syscall
  40009b:       b8 3c 00 00 00          mov    $0x3c,%eax
  4000a0:       bf 00 00 00 00          mov    $0x0,%edi
  4000a5:       0f 05                   syscall

>>958079

>>958073

>>958086

You idiots do realize that 99% of that is the baseline cost of the runtime that is amortized away instantly.

>>958092

>it amortizes away, goyim!

It's bloated in benchmark tests, too. It's just a bloated language.

>>958095

You must really not understand how amortized costs work.

>>958132

>comparing LITERALLYANYTHING to THEFASTESTLANGUAGE

lol

All these shitty webdev languages aren't going to survive when we hit the physical limits of miniaturization soon and can only go faster through better code. If they can't compete with C, they aren't worth learning.

>>958134

>can only go faster through better code.

And that better code wont be c

>>958135

>And that better code wont be c

Looks like it will be, as it hasn't been dethroned after 46 years of attempts.

>>958136

Only because of legacy shit started in the 90s. C++ has killed it in high performance areas.

>>958136

C is only faster in the same way assembly is faster than anything. Highly optimized c code looks nothing like 99% of the real world bullshit anyone writes. Here is a quick example. Take a linked list. In c to make a generic version (where you don't copy and paste the same code 50 times) you have to have the value element be a void*. That means you have a layer of indirection between the value and cell. Horribly slow. In something like c++ you can use templates (like the STL does) to just have the value be a part of the linked list node.

>>958140

>C++ has killed it in high performance areas

C++ is no faster.

>That means you have a layer of indirection between the value and cell. Horribly slow.

Lists in C aren't written that way by good programmers. Proper linked lists are intrusive and use knowledge of the offset of the embedded node to load the pointer to the object without an additional deference. An example of this is Linux's list library, but you'll find something similar in every good C project. See here for a description of how it works:

https://isis.poly.edu/kulesh/stuff/src/klist/

>In something like c++ you can use templates

Templates are a disaster for fast code as all the fun toys the processor has to speed up code like the icache and branch predictor get overwhelmed by all the copies of nearly identical code you throw at it. That kind of code explosion only appears to speed up poorly optimized code that wasn't tight enough to see the benefits of what was lost.

>>958155

>C++ is no faster.

Bullshit almost every part of real world c++ is faster.

>Lists in C aren't written that way by good programmers.

Yes "good" c programmers implement the same data structure over and over and over instead of using a well optimized known good version because c lacks any form of non retarded generics.

>roper linked lists are intrusive and use knowledge of the offset of the embedded node to load the pointer to the object without an additional deference

Which is what type safe c++ code does for you.

>but you'll find something similar in every good C project.

Because C makes doing trivial things like a generic list impossible

>Templates are a disaster for fast code

Wrong. Template code duplication was a problem like 20 years ago man.

>by all the copies of nearly identical code you throw at it.

You do realize that all your macro hack bullshit does the same thing though worse and is even less likely to be optimized away.

>>958158

>Bullshit almost every part of real world c++ is faster.

Untrue. The language benchmark site is a good example as their C++ tests are written with the restriction that they be written like real-world C++ rather than just copypaste the C. In the real world, we write the fast parts of C++ code as if it were C and use C++'s features to reduce the amount of error handling.

>because c lacks any form of non retarded generics.

Fast code doesn't use STL generics as many of the algorithms are undefined so can have wildly varying performance characteristics and are usually too generic and bloated to be any good. Only the more modern parts of the standard are free of that mistake, like the new RNG layer in C++14.

>Which is what type safe c++ code does for you.

No, actually. STL lists are worse than C lists and don't allow having an object in multiple lists. If you want the performance of C lists in C++ you can use the boost intrusive library. I'll caution you that this also gets used as an example when arguing why you shouldn't use C++. Try it and find out why.

>Because C makes doing trivial things like a generic list impossible

I literally just linked you to the kernel's generic list in C...

>Template code duplication was a problem like 20 years ago man

Nothing has changed. You have to be very careful with templates.

>You do realize that all your macro hack bullshit does the same thing though worse

It doesn't. You need to spend some time testing these things with objdump --disassemble so you don't sound like a faggot when arguing with a programmer.

>>958170

>>958169

Again you faggot. C will be fast for microbenchmark bullshit for the same reason assembly will be faster than anything. It has NO RELATIONSHIP to how data structures are actually used in the real world.

>I literally just linked you to the kernel's generic list in C...

Did you even read the shit you linked you retard? This is YET ANOTHER EXAMPLE of macros being used to DUPLICATE CODE in a SHITTY WAY compared to c++. Copy and pasting code with Macros is sure as fuck going to have the same or worse optimization results.

>>958169

>STL lists are worse than C lists and don't allow having an object in multiple lists

Yeah i'm sure pointers don't exist in c++

>>958191

>It has NO RELATIONSHIP to how data structures are actually used in the real world

And yet I showed you that real-world kernel code handles data structures that way. How embarrassing for you.

>>958192

>DUPLICATE CODE

It's a bizarro world complaint coming from a C++ fan, but you're free to compare klist and boost intrusive - they'll both compile to the same code if you set the options in boost intrusive correctly. I think if you tried seriously using boost intrusive (both at class level and member level) you'd walk away with a desire to use klist and an understanding of why people hate C++, though. Go on, try it out. Learn something new today.

>>958193

>Yeah i'm sure pointers don't exist in c++

You don't understand the differences in how those datastructures work. Try creating a class that can be simultaneously present in 0, 1, or 2 lists with a STL list<>. Or, try creating a class that can be moved between different lists without duplicating the list node. Or just look up why boost intrusive exists.

>>958202

>c programmers link to microbenchmarks to make their point

this is a real plebian mistake

>real-world kernel code handles data structures that way

Yep and what do they do? COPY PASTING WITH MACROS. Now try shit like string optimizations. There is so much shit that c++ does superior string representations that you just never find in most c.

>You don't understand the differences in how those datastructures work.

<hurr durr he does not know how a linked list works

look faggot just because one particular data structure does not expose the cells of your list does not mean you cant have a pointer to a cell in general.

>>958205

>c programmers link to microbenchmarks to make their point

Optimization is all about taking the hot loop and transforming it into a horrible nightmare of "microbenchmark" style code. It's entirely relevant.

>Now try shit like string optimizations. There is so much shit that c++ does superior string representations that you just never find in most c

Uhh anon, I guess you aren't aware that C++ strings are hopelessly and absurdly slow, so much so that they're usually forbidden in coding standards of large C++ projects. You should really write a little benchmark and see for yourself. The problem is with the standard - because the stringbuf stuff is virtual, it can't ever be optimized away by any compiler and you end up with cases where it's calling a virtual method per character. They're literally the worst part of C++ and a tragic mistake. They also are a total failure for unicode. Real C++ code often uses ICU strings instead.

> just because one particular data structure does not expose the cells of your list does not mean you cant have a pointer to a cell in general

I have no idea what you're talking about. Why don't you actually try what I suggested so what you say isn't so retarded? It's a learning opportunity. Use boost intrusive with the same settings that would match klist's behavior, examine the code produced, try to match it using the STL. And presto, you'll have an understanding of what's wrong with the STL. It's like 10 lines of code, you can do it, I believe in you.

>>958144

https://isis.poly.edu/kulesh/stuff/src/klist/

>>958192

You realize that the compiler instantiates templates, right? Not very different from macro expansion.

FYI the biggest and most important advantage C has that C++ never will have is a stable ABI. That's why people use C libraries from any language while the only code that will ever touch C++ shit is more C++ code unless you give up on C++ interfaces and use extern "C".

>>958216

>Real C++ code often uses ICU strings instead.

You're my nigger. ICU is amazing.