1,241,588 events, 558,250 push events, 890,891 commit messages, 78,242,709 characters
Update from Forestry.io Greg Storey created content/post/appwalls-and-their-stupid-apps-are-sucking-the-life-out-of-the-world-wide-web.md
Squash zero width unicode characters (#77)
- Squash zero width unicode characters
Fuck you zero width unicode characters
-
blackening code
-
Add _cast_to_ascii casting function
This simplifies and makes casting a string that strips unicode characters reusable.
Archive management update
FIXED THE FUCKING GOD DAMNED MANGA LEGACY CODE AND UNEXPECTED END OF DATA ERROR ON THE ARCHIVES FOR THE FUCKING 100TH TIME.
Some very nice issue reports have helped correct various corner case issues. Mint users helped find a big one with lspci.
KNOWN ISSUES:
- Unsure how to handle Android case where inxi correctly does -r test, see bug 3 fixes 6, but android incorrectly claims it is readable when it is not readable, then the reader tool can't read the file and fails with permissions error. This is one of those weird android errors that are pretty much impossible to fully work around, but we can get rid of the readline() errors when reader() was trying to work on a file handle that did not exist, that part was an inxi bug.
BUGS:
-
dm detection was not using case sensitive search for duplicates, leading to cases where dm like slim / SLiM failed to get detected and then repeated in output. Anonymous BSD debugger dataset exposed this issue, thanks.
-
In certain corner cases, like ARM Android, sub reader got passed a file that had passed the is readable -r test, but it still failed with permissions error, which then led reader to try to keep working with a null $fh. While in theory nothing non readable should be passed to reader(), that fails when the OS fails to actually follow correct readable rules, as in this case. Added protections in reader() to handle this case, now will show error, but will not try to work with $fh, that is how it should have been all along, but this is a very corner case. Exposed by an anoymous ARM debugger dataset.
Thanks Termux user for creating the debugger dataset that exposed this issue.
-
lspci parser didn't null port value each iteration, resulting in all pci items getting port values. Not a big deal, port is only used one place, but good to find and correct that error.
-
Not an inxi bug, but would appear so to end users: lspsci -nnv implements a truncating routine and breaks the first line for each bus id. See Fix 6 and Code fix 3.
FIXES:
- -S and -I would show Console: tty pts/3 even though pts device is a pty, not a tty. The only time this happened was when connecting to a remote system using ssh or something like that. Local console still shows Console: tty 2 since that was correct, but Console: tty pts/2 was confusing since technically it's not a tty, it's a pty, pseudo terminal.
Now shows, when relevant: Console: tty 2 OR Console: pty pts/2.
- Issue #252 notes that Emacs (and possibly other code/text editors with native embedded terminals) includes a native virtual terminal that also follows configuration rules from the editor to highlight trailing spaces. This created odd looking screen output in Emacs vt mode since inxi always sets key/value pairs with a white space ending as separator for next key value pair for screen output mode, resulting always in a trailing space on each vt screen line. Fix was to remove the last trailing space just prior to the print line point to avoid this issue.
As a general thing, I'm curious to learn if any editor other than Emacs actually contains its own virtual terminal that also follows the editor rules for output. Or if any virtual terminal has such a highlight trailing space rule, which would be imo so annoying it's hard to understand why a vt would implement it. Easy to understand why Emacs (or any editor) does it, but an editor also being a vt AND applying certain editor display configurations to the vt is a very specific and unique circumstance I'd say.
Odd, historical, but there it is, why not handle it?
-
ARM / Android case where certain files passed the read -r test, but failed with permission denied error. This tripped a further glitch where reader() would then try to work with the failed $fh, see bug 2. This was really more a fix than a bug, since the bug in this case was in android permissions tests, not inxi, but it appears to be a bug to end users, so it's handled now.
-
Another ARM/Android, there was a voltage regulator IP that contained the term wlan so it tripped false positive for network match. Added a new type, regulator, to filter out those, like codec and dummy do already.
-
For issue #254, fix for cygwin ERR-102 in partitions, add cygwin test, new dev type, 'windows', dev base then becomes E: or whatever. To avoid confusing D: for a key: with no value, added D:/ slash.
-
Mint people discovered lspci issue, lspci -nnv has a bug where it will truncate the output of the first line per bus ID if it's over some arbitrary amount, then tack on rev and other items to end of that string, which leads to the block: [vendorID:productID] getting truncated or removed altogether. Clearly an oversight, at least I hope it's an oversight on lspci's part, but have to work around the issue anyway since it may never get fixed, and has been around a long time. Bug is in lspci 3.7, 3.6.4, and probably earlier.
Also added in a fillin tool for this rare case, lspci -n data is used to replace the missing values.
Note that while lspci recommends using -mmv, for machine parsing, apparently nobody noticed that -mmv doesn't have the same data items as -nnv, sigh.
- Issue #255 noted that the combination of: GoogleDrive Hogne: fuse.rclone 15728640 which is two word remote fs AND a fs type with a '.' in it would fail to trip the handler for that multi word remote mount name. Also failed to detect as remote fs, added fs specific test since the actual mount name doesn't permit reliable detection as remote type. Testing for trailing ':' isn't safe since ':' alone is not an invalid character in a file system name as far as I know.
Further, this exposed that the ^^ space replacements for $row[0] fs > 1 word name were not being reset soon enough in the logic, that's also corrected.
ENHANCEMENTS:
-
Neglected to support standard package config file override /etc/inxi.d/inxi.conf item. This is mainly useful for packaged inxi's who want to override the distro maintainer /etc/inxi.conf file. Test priority is the same except /etc/inxi.d/inxi.conf comes right after /etc/inxi.conf now in the test sequence.
-
Added basic cygwin id, yes, inxi works in cygwin, apparently, with some issues. Added cygwin os id to distro ids.
-
Added --version info for debugger, sometimes we want to know what verion of a tool, like lspci, in case it has a bug or something.
-
Added exfat and apfs to unmounted fs types.
-
More disk vendors!! New vendor ID matches!! Yes, yes, you've heard it all before, the list never ends!! The eternal chaos of existence manifested in just how many IDs can be generated for new and old disk vendors alike!!!
CHANGES:
- No changes this release.
DOCUMENTATION:
- Pull request #253 corrected typos, urls, and other errors in man page, inxi/pinxi comments, pinxi.1/inxi.1, README.txt, and updated LICENSE.txt to current gnu wording.
CODE:
-
Forgot to add lspci debugger fake data option, that's corrected. That's --fake lspci, now works, didn't before, only the bsd pci tools had fake switches previously, since lspci never needs debugging really, but did now to test an issue report.
-
Added -CYGWIN to debugger file name. Added -ANDROID if ARM and if android.
-
With Fix 6, refactored entire lspci_data block, added lspci_n_data item, which matches bus id of lspci -nnv when corruption occurs and replaces vendor, product, and if also missing, rev version. I kind of knew I'd have to do this fix one day, that was the same fix logic used on the BSD pci tools, which have similar issues with consistency in output, or lack thereof.
This refactor is long term very good because it avoids an entire class of possible errors, and makes pci detections far more robust.
- Created new repo, for legacy code, inxi-legacy. Moved branch inxi-c to inxi-legacy/xorg-c, moved branch xiin to /xiin, moved branch inxi-legacy (binxi) to inxi-legacy/inxi-legacy. Those directories each contain all the files each branch had in it.
This gets rid of some branches clutter, and nobody needs to see those anymore, but if they care, they can look at them. Note that to do this, I had to merge their histories, which was not that nice, but git is just really bad at this type of stuff, so that's how it goes.
Times like this really make me miss svn's directory based branch approach...
-
Simplified sub fs_excludes, simplified regex constructors for all function that use this data, made list more fault tolerate by adding global (fs)?(\d{0,2} which means all file systems can have or not have 'fs' at end, and all can have or not have a version number in string.
-
Exposed by issue #255, refactored slightly ordering of partition filter logics and variable resets in the df output processing loop.
-
Added --fake partitions, to help debug odd corner cases like cygwin glitches.
Maintain morality, ethics, humanitarian liberties, share society Good parents value the weak common sense of good and evil.
Maintain morality, ethics, humanitarian liberties, share society Good parents value the weak common sense of good and evil. Human sympathy for natural water bodies and the volatility of natural water bodies. Responding to a good mind with virtue Responsible for helping communities achieve equality, happiness, pure smiles. Giving love to each other, good heart, creating a profitable career, respecting others, striving to work and develop for the public. It does not discriminate against national communities, color, age, gender, nationality, religion. We hope the outcome will be a happy outcome for friendship without borders. lead to peace Meaning of all religions, goodness, morality, responsibility, environment, the discipline of morality. fully contribute to society Add tools to manage well-being, healthy, clean, bright, leading to God. Children are the purest things we must protect most for the future of society in guiding today's emerging communities to the happiness, appreciation, learning, love, respect, sharing, and equality of natural communities. Honest friendship for the global food chain Security, quality of accommodation Caring for the Elderly, the Disabled, the balance of reality must be permanently composed of the Spirit of God.
Update from Forestry.io Greg Storey updated content/post/appwalls-and-their-stupid-apps-are-sucking-the-life-out-of-the-world-wide-web.md
[PATCH] TTY layer buffering revamp
The API and code have been through various bits of initial review by serial driver people but they definitely need to live somewhere for a while so the unconverted drivers can get knocked into shape, existing drivers that have been updated can be better tuned and bugs whacked out.
This replaces the tty flip buffers with kmalloc objects in rings. In the normal situation for an IRQ driven serial port at typical speeds the behaviour is pretty much the same, two buffers end up allocated and the kernel cycles between them as before.
When there are delays or at high speed we now behave far better as the buffer pool can grow a bit rather than lose characters. This also means that we can operate at higher speeds reliably.
For drivers that receive characters in blocks (DMA based, USB and especially virtualisation) the layer allows a lot of driver specific code that works around the tty layer with private secondary queues to be removed. The IBM folks need this sort of layer, the smart serial port people do, the virtualisers do (because a virtualised tty typically operates at infinite speed rather than emulating 9600 baud).
Finally many drivers had invalid and unsafe attempts to avoid buffer overflows by directly invoking tty methods extracted out of the innards of work queue structs. These are no longer needed and all go away. That fixes various random hangs with serial ports on overflow.
The other change in here is to optimise the receive_room path that is used by some callers. It turns out that only one ldisc uses receive room except asa constant and it updates it far far less than the value is read. We thus make it a variable not a function call.
I expect the code to contain bugs due to the size alone but I'll be watching and squashing them and feeding out new patches as it goes.
Because the buffers now dynamically expand you should only run out of buffering when the kernel runs out of memory for real. That means a lot of the horrible hacks high performance drivers used to do just aren't needed any more.
Description:
tty_insert_flip_char is an old API and continues to work as before, as does tty_flip_buffer_push() [this is why many drivers dont need modification]. It does now also return the number of chars inserted
There are also
tty_buffer_request_room(tty, len)
which asks for a buffer block of the length requested and returns the space found. This improves efficiency with hardware that knows how much to transfer.
and tty_insert_flip_string_flags(tty, str, flags, len)
to insert a string of characters and flags
For a smart interface the usual code is
len = tty_request_buffer_room(tty, amount_hardware_says);
tty_insert_flip_string(tty, buffer_from_card, len);
More description!
At the moment tty buffers are attached directly to the tty. This is causing a lot of the problems related to tty layer locking, also problems at high speed and also with bursty data (such as occurs in virtualised environments)
I'm working on ripping out the flip buffers and replacing them with a pool of dynamically allocated buffers. This allows both for old style "byte I/O" devices and also helps virtualisation and smart devices where large blocks of data suddenely materialise and need storing.
So far so good. Lots of drivers reference tty->flip.*. Several of them also call directly and unsafely into function pointers it provides. This will all break. Most drivers can use tty_insert_flip_char which can be kept as an API but others need more.
At the moment I've added the following interfaces, if people think more will be needed now is a good time to say
int tty_buffer_request_room(tty, size)
Try and ensure at least size bytes are available, returns actual room (may be zero). At the moment it just uses the flipbuf space but that will change. Repeated calls without characters being added are not cumulative. (ie if you call it with 1, 1, 1, and then 4 you'll have four characters of space. The other functions will also try and grow buffers in future but this will be a more efficient way when you know block sizes.
int tty_insert_flip_char(tty, ch, flag)
As before insert a character if there is room. Now returns 1 for success, 0 for failure.
int tty_insert_flip_string(tty, str, len)
Insert a block of non error characters. Returns the number inserted.
int tty_prepare_flip_string(tty, strptr, len)
Adjust the buffer to allow len characters to be added. Returns a buffer pointer in strptr and the length available. This allows for hardware that needs to use functions like insl or mencpy_fromio.
Signed-off-by: Alan Cox [email protected] Cc: Paul Fulghum [email protected] Signed-off-by: Hirokazu Takata [email protected] Signed-off-by: Serge Hallyn [email protected] Signed-off-by: Jeff Dike [email protected] Signed-off-by: John Hawkes [email protected] Signed-off-by: Martin Schwidefsky [email protected] Signed-off-by: Adrian Bunk [email protected] Signed-off-by: Andrew Morton [email protected] Signed-off-by: Linus Torvalds [email protected]
[PATCH] Fix ext2 readdir f_pos re-validation logic
This fixes not one, but two, silly (but admittedly hard to hit) bugs in the ext2 filesystem "readdir()" function. It also cleans up the code to avoid the unnecessary goto mess.
The bugs were related to re-valiating the f_pos value after somebody had either done an "lseek()" on the directory to an invalid offset, or when the offset had become invalid due to a file being unlinked in the directory. The code would not only set the f_version too eagerly, it would also not update f_pos appropriately for when the offset fixup took place.
When that happened, we'd occasionally subsequently fail the readdir() even when we shouldn't (no real harm done, but an ugly printk, and obviously you would end up not necessarily seeing all entries).
Thanks to Masoud Sharbiani [email protected] who noticed the problem and had a test-case for it, and also fixed up a thinko in the first version of this patch.
Signed-off-by: Al Viro [email protected] Acked-by: Masoud Sharbiani [email protected] Signed-off-by: Linus Torvalds [email protected]
giflib: abandon efforts for now
Now I'm remembering why I didn't do this sooner. (I first attempted this integration a few years back, but it didn't go well. I thought I'd try again but argh this is a time-consuming and error-prone project)
The giflib maintainer is (to quote his own words) "totally uninterested in supporting Windows" - https://sourceforge.net/p/giflib/feature-requests/6/ - and it shows. Building giflib on Windows is doable, but only as a static library. As a DLL there are myriad issues that I don't want to waste energy debugging (see the giflib bug reports - I'm far from the only one encountering this)
The standard reply seems to be to use the 4.x line which had different API signatures (and a different maintainer), and I'd be down for that except that it's a lot of work to track down legacy docs. Honestly, I'd probably rather just wrap the (meh quality) GDI+ GIF encoder that works on Win 7+ and just enable that conditionally, since it's at least zero-dependency.
Anyway, this is all somewhat unnecessary as PD already supports GIFs just fine via FreeImage. I'm just not happy with FreeImage's terribly slow performance and mediocre GIF compression, and I'd hoped this would be a relatively simple transition. Alas.
I'll leave this branch live for awhile yet, but I'm not going to waste more time on this right now
clocksource: introduce CLOCK_MONOTONIC_RAW
In talking with Josip Loncaric, and his work on clock synchronization (see btime.sf.net), he mentioned that for really close synchronization, it is useful to have access to "hardware time", that is a notion of time that is not in any way adjusted by the clock slewing done to keep close time sync.
Part of the issue is if we are using the kernel's ntp adjusted representation of time in order to measure how we should correct time, we can run into what Paul McKenney aptly described as "Painting a road using the lines we're painting as the guide".
I had been thinking of a similar problem, and was trying to come up with a way to give users access to a purely hardware based time representation that avoided users having to know the underlying frequency and mask values needed to deal with the wide variety of possible underlying hardware counters.
My solution is to introduce CLOCK_MONOTONIC_RAW. This exposes a nanosecond based time value, that increments starting at bootup and has no frequency adjustments made to it what so ever.
The time is accessed from userspace via the posix_clock_gettime() syscall, passing CLOCK_MONOTONIC_RAW as the clock_id.
Signed-off-by: John Stultz [email protected] Signed-off-by: Roman Zippel [email protected] Signed-off-by: Andrew Morton [email protected] Signed-off-by: Ingo Molnar [email protected]
Introduce FW_BUG, FW_WARN and FW_INFO to consistenly tell users about BIOS bugs
The idea is to add this to printk after the severity: printk(KERN_ERR FW_BUG "This is not our fault, BIOS developer: fix it by simply add ...\n");
If a Firmware issue should be hidden, because it is work-arounded, but you still want to see something popping up e.g. for info only: printk(KERN_INFO FW_INFO "This is done stupid, we can handle it, but it should better be avoided in future\n");
or on the Linuxfirmwarekit to tell vendors that they did something stupid or wrong without bothering the user: printk(KERN_INFO FW_BUG "This is done stupid, we can handle it, but it should better be avoided in future\n");
Some use cases:
-
If a user sees a [Firmware Bug] message in the kernel he should first update the BIOS before wasting time with debugging and submiting on old firmware code to mailing lists.
-
The linuxfirmwarekit (http://www.linuxfirmwarekit.org) tries to detect firmware bugs. It currently is doing that in userspace which results in: - Huge test scripts that could be a one liner in the kernel - A lot of BIOS bugs are already absorbed by the kernel
What do we need such a stupid linuxfirmwarekit for?
-
Vendors: Can test their BIOSes for Linux compatibility. There will be the time when vendors realize that the test utils on Linux are more strict and using them increases the qualitity and stability of their products.
-
Vendors: Can easily fix up their BIOSes and be more Linux compatible by: dmesg |grep "Firmware Bug" and send the result to their BIOS developer colleagues who should know what the messages are about and how to fix them, without the need of studying kernel code.
-
Distributions: can do a first automated HW/BIOS checks. This can then be done without the need of asking kernel developers who need to dig down the code and explain the details. Certification can/will just be rejected until dmesg |grep "Firmware Bug" is empty.
-
Thus this can be used as an instrument to enforce cleaner BIOS code. Currently every stupid Windows ACPI bug is re-implemented in Linux which is a rather unfortunate situation. We already have the power to avoid this in e.g. memory or cpu hot-plug ACPI implementations, because Linux certification is a must for most vendors in the server area. Working towards being able to do that in the laptop area (vendors are starting to look at Linux here also and will use this tool) is the goal. At least provide them a tool to make it as easy for this guys (e.g. not needing to browse kernel code) as possible.
-
The ordinary Linux user: can go into the next shop, boots the firmwarekit on his most preferred machines. He chooses one without BIOS bugs. Unsupported HW is ok, he likes to try out latest projects which might support them or likes to dig on it on his own, but he hates to workaround broken BIOSes like hell.
I double checked with the firmwarekit. There they have: So the mapping generally is (also depending on how likely the BIOS is to blame, this could sometimes be difficult): FW_INFO = INFO FW_WARN = WARN FW_BUG = FAIL
For more info about the linuxfirmwarekit and why this is needed can be found here: http://www.linuxfirmwarekit.org
While severity matches with the firmwarekit, it might be tricky to hide messages from the user. E.g. we recently found out that on HP BIOSes negative temperatures are returned, which seem to indicate that the thermal zone is invalid. We can work around that gracefully by ignoring the thermal zone and we do not want to bother the ordinary user with a frightening message: Firmware Bug: thermal management absolutely broken but want to hide it from the user.
But in the linuxfirmwarekit this should be shown as a real show stopper (the temperatures could really be wrong, broken thermal management is one of the worst things that can happen and the BIOS guys of the machine must implement this properly).
It is intended to do that (hide it from the user with KERN_INFO msg, but still print it as a BIOS bug) by: printk(KERN_INFO FW_BUG "Negativ temperature values detected. Try to workarounded, BIOS must get fixed\n"); Hope that works out..., no idea how to better hide it as printk is the only way to easily provide this functionality.
Signed-off-by: Thomas Renninger [email protected] Signed-off-by: Andi Kleen [email protected] Signed-off-by: Len Brown [email protected]
"8:05am. Let me chill just a bit and then I will start.
I did the right thing by running away from the PPL job. Even as a part of cultivating my old path, it was a desperation move. None of the current crop of algorithms matter. If only I could get a hint of what the brain is doing, I could make so much progress.
8:10am. I could do so much if I had the right insights, and yet no matter the effort, I do not have them.
https://arxiv.org/abs/2010.08262 Local plasticity rules can learn deep representations using self-supervised contrastive predictions
Let me read this paper just for a bit.
8:40am. I still haven't started reading it. Let me do so. After that comes the 3d shapes tutorial. I cannot do this forever. If it has been my father who had cancer instead of my mother I'd have gotten some backend job already. I absolutely have to get some kind of income from this attempt or the journey to transcende will turn into wage slavery pretty quickly.
9am. Ok, enough. Let me start.
9:10am. https://youtu.be/qpqEE9yU474?t=600
He outright suggests to master the fundamentals before getting mixed up in a style.
His drawing is quite precise and his handwriting is neat.
9:20am. It will be worth it to wait a few years so the local rules such as the above improve and then try them out on AI chips. I won't worry about that for the time being.
https://youtu.be/qpqEE9yU474?t=1032
This is making me think that I might be going the wrong way with the illustrator. Maybe I should be learning a 3d program instead?
While I am watching this let me get Clip Studio.
https://youtu.be/qpqEE9yU474?t=1459
This brief history lesson is interesting. He says that during the middle ages, the artists collectively lost grasp on the concept of 3 dimensionality. It was only rediscovered during the rennaisance.
9:45am. It really is a decent idea to learn some 3d modeling. The reason why I am poor at drawing the hand directly is because I do not have a 3d shape in mind when I do it. Instead trying to strain my brain to translate 3d from my imagination to 2d curves, in lieu of sketching, I should bring in 3d models. That might give me some insight.
9:50am. https://www.google.com/search?q=adobe+illustrator+3d
Hmmm, it does seem like the Illustrator has some 3d functionality. I should look into it.
10am. Let me install Clip Studio. Full version of course.
https://youtu.be/qpqEE9yU474?t=2380
It is really not a viable approach for me to get such good hand drawing skills in the short term. I do not want to get a tablet at this juncture and practice my hand drawing skills. For the game art, of course I'd want to trace as much as possible. 3d modeling is a part of me learning how to cheat at art.
That is the way I will roll - by using the power of the machines to their fullest.
11:55am. Had to take a break. Let me finish watching the video and then I will have breakfast.
https://youtu.be/qpqEE9yU474?t=7425
Here he is drawing a hand. It is like magic the way my perception shifts.
12:25pm. https://www.youtube.com/playlist?list=PLMXbAPr21di-Ox-dmDwL2riWedei1dn9S
This guy has a lot of stuff. I'll skip watching anything more from now. I should have skipped the video I watched as well, but it is an adventure, so I went for it.
Next thing my list is to check out 3d functionality of Illustrator and after that take a look at 3d modelling in general. If it is extending 3d shapes that I have to learn, it makes sense to start with a 3d program. That might give me some inspiration.
12:35pm. Let me have breakfast here.
1:15pm. Done with breakfast and chores.
1:20pm. Now let me check out the 3d Illustrator stuff.
1:30pm. It is just an effect, nevermind that. Let me try doing some drawing on my own. I want to try immitating what I saw in those videos.
1:40pm. It just looks like ugly doll hands when I try to do it like this. I do not know, I can't really capture the feel.
Tracing out everything is a bit too much - I should be more ambitious, but learning drawing fundamentals would take too long as well. So tracing 3d models could be a good intermediate step. Let me take a look at the 3d modeling tutorials. I'll learn to draw properly once I have time.
https://www.youtube.com/watch?v=Ey7zoszKHZQ 3D Modelling - Noob to Pro - Basic Steps
1:55pm. https://www.youtube.com/watch?v=mrHQRJL0W84 Blender - Girl in Uniform
Let me watch this. Learning how to work with 3d shapes should improve my understanding of what exactly am I lacking in the 2d world.
https://youtu.be/mrHQRJL0W84?t=62
Oh wow, I like this. Staring out with simple shapes and then making them more complex is exactly how envisioned art should be made. I just can't get a grip on that in Illustrator.
Maybe if I had been taught properly as a kid things would have been different, but I want to take a different approach than just trying to make the lines match up with my imagination.
https://youtu.be/mrHQRJL0W84?t=100
Here is the fabled hand.
https://youtu.be/mrHQRJL0W84?t=176
Looks spooky at this point.
2pm. Being able to this so smoothly...this guy is quite skilled. I bet for male and female characters there will be plenty of models I could study.
2:15pm. https://youtu.be/mrHQRJL0W84?t=925
Doing all this is probably way more work than just drawing the character outright for one who is a skilled artist. But for me studying these models and replicating them, as well as tracing them in Illustrator should put me on the path of gaining some actual skill.
I'll want to watch some more Blender tutorials. I'll do that for a while, and then I'll start with the hand.
The way he started with just a bunch of squares and then refined them makes me think that this is how I should be doing things. I think a lot of digital artists actually do the thing of tracing their 3d work. The author of Gunnm (Yukito Kishiro) and UQ Holder (Ken Akamatsu) probably do this. I don't dislike that style at all. If I could do that, I'd be perfectly happy to call myself an artist.
Don't get me wrong tracing, shading and coloring quickly in Illustrator is definitely a skill in itself, but there is a huge difference in being able to do it quickly and slowly, and slowly and not at all. I want to cover that gap.
2:20pm. As for musical composition, I've never tried it even once, but I think I'll manage to handle that. Much like writing, I feel it will be easier than drawing.
2:30pm. https://youtu.be/mrHQRJL0W84?t=1406
What is he doing here? It looks like a skeleton.
https://youtu.be/mrHQRJL0W84?t=1471
Yeah, now he can move her body and have her do poses. Remarkable. I didn't think that would be possible.
The reality of my present situation is that even though I am 34 years old, it is not like have any particular advantages at learning to how draw compared to 20-25 years ago. When I was a kid I thought I'd get some adult superpowers, but adults get squat. Maturity means absolutely nothing when considering power.
I can only attempt to learn art more intelligently than I would have than if I were a kid. I can only take a different approach and put in the effort now that I am not busy with school.
2:35pm. https://youtu.be/mrHQRJL0W84?t=1536
Being able to do this kind of thing would be great for learning anatomy. The Drawing Database guy said that I should not get caught up in style, but instead learn the underlying constructions. I'll take that advice to heart.
2:50pm. The comments are full of praises. I thought it was amazing myself.
Let me download Blender.
2:55pm. https://youtu.be/jA0IDJy5AcU Is Blender Hard to Learn?
Let me watch this vid and then I'll watch another one of those guy's vids.
https://www.youtube.com/watch?v=LFW6iq74WpA Blender MMORPG Game Character creation
Here is more FlyCat. Let me watch this for inspiration. After that what I will do is go to the Blender site, and check out the tutorials on it.
https://youtu.be/LFW6iq74WpA?t=168
Interesting how he is using the head to measure the height of the body.
3:40pm. https://youtu.be/LFW6iq74WpA?t=937
He is good at doing the clothing design too.
3:50pm. https://youtu.be/LFW6iq74WpA?t=1443
I saw something like this in the previous video. I wonder what it is?
https://youtu.be/LFW6iq74WpA?t=1865
This guy has mastered what would be my ideal style. What I want to do is manga style portraits and backgrounds, but in terms of workflow I want it to 100% be this. So I'll prioritize workflow instead.
I've looked around and it seems that Blender is completely dominant compared to 3DS and Maya. There aren't any videos except for it unlike say 2d programs where PS,AI and CP seem all be popular.
Oh the video is 1080p and my screen is 720p. Foolish me.
4:10pm. https://youtu.be/LFW6iq74WpA?t=2260
A very cute alien. 10/10 loli waifu.
Looking at the sidebar, there seems to be a bunch of anime related stuff by other people. Yeah, I am in the right place here.
4:20pm. On Blender's site:
///
Story Art, Drawing 2D in 3D Really! Drawing directly in a 3D viewport makes a lot of sense. It opens unsurpassed workflow freedom for story-boarders and 2D artists.
· Combine 2D with 3D right in the viewport · Full Animation Support with Onion Skinning · Layers & Colors for Stroke and Fill · Sculpt brush strokes & Parent to 3D objects
///
This has my interest.
4:20pm. I realized I haven't checked my mail in a week. Let's see...got a reject from Mittel, nevermind it.
Interesting that Theorem is offering to actually extend the time I need to take the assessment. It expired a while ago as I said I would let it.
I think this is the way it goes, I applied to about a dozen places, and got insta-rejected from all but 2. From what I hear, this seems to be standard.
Honestly, it is not too bad, since one only needs a single job. It might be plausible that I could get one if I could put in the effort to learn the frameworks of the day.
That is in the past.
I want to learn art so I can make Heaven's Key. I am not one for drone corporate life.
I'll be interested in programming when a better ML algo comes out.
4:25pm. Oh yeah, I wanted to talk about sleeping. I think that if the brain's algorithm is approximately doing immutable updates in essence during waking time, and then compressing them during the night for the sake of long term storage, that would make an extreme amount of sense.
Deep learning does not even come close to this. Come to think of it, remember what Hinton said about how much information backprop can squeeze into a single cubic centimeter - enough to cover pretty much all language.
It might turn out that backprop is storing information in very compressed form, and the demands of continual learning require something different.
4:35pm. I just have no idea how once can loosely store the data using Hebbian updates, only to later compress and transfer them into long term storage. That kind of control, plus the net being able to learn in an arbitrary fashion and yet the natural instincts knowing to how to make use of it is beyond me.
What Hawkins says about neocortex being an unsupervised algorithm with immutable updates and other properties seems very likely. Backprop based approaches are just too difficult to handle, nature would have ditched those. I need something like that. I need something that is roboust, modular and easy to handle. I want something that I could point at the data and do a good job regardless.
It can take 10x the number of parameters as backprop or even 100x to get the same result. I do not care about this.
I need stability and modularity. If I had that I could take the world.
4:40pm. Let me check out the Blender basics, though I do not feel like it right now.
https://cloud.blender.org/training/?training_date_desc%5Bmenu%5D%5Bdifficulty%5D=beginner
There is all sorts of stuff here. Let me start with 2.8 fundamentals.
...
https://www.youtube.com/watch?v=7MRonzqYJgw Complete Beginners Guide to Blender 2.8 | Free course | Part 1 | The Interface
Let me instead go for this. I do not want to start off by having it just explain what a particular key does. I'd like to have a goal to start things off.
4:50pm. I like how this video starts from the entry screen instead of just diving into it.
5:55pm. https://www.youtube.com/playlist?list=PLn3ukorJv4vs_eSJUQPxBRaDS8PrVmIri Blender 2.8 for beginners full course
I've gone through the first video. It was only 20m, but it took me an hour due to all the playing around. This is fun.
6pm. I'll call it a day here though.
I just got an idea. If I had that neo-cortical algorithm, I could train it to predict the scene as I create and pick from its predictions. If that could be gotten to work, it could improve my efficiency as much as 100x. It would be absolutely remarkable.
6:10pm. There are a lot of applications of having an agent predict my own actions and mapping them to some finished result. One of which would be UI automation for poker. Right now that would be completely out of the question."
proc: move fd symlink i_mode calculations into tid_fd_revalidate()
Instead of doing the i_mode calculations at proc_fd_instantiate() time, move them into tid_fd_revalidate(), which is where the other inode state (notably uid/gid information) is updated too.
Otherwise we'll end up with stale i_mode information if an fd is re-used while the dentry still hangs around. Not that anything really cares (symlink permissions don't really matter), but Tetsuo Handa noticed that the owner read/write bits don't always match the state of the readability of the file descriptor, and we used to get this right a long time ago in a galaxy far, far away.
Besides, aside from fixing an ugly detail (that has apparently been this way since commit 61a28784028e: "proc: Remove the hard coded inode numbers" in 2006), this removes more lines of code than it adds. And it just makes sense to update i_mode in the same place we update i_uid/gid.
Al Viro correctly points out that we could just do the inode fill in the inode iops ->getattr() function instead. However, that does require somewhat slightly more invasive changes, and adds yet another lookup of the file descriptor. We need to do the revalidate() for other reasons anyway, and have the file descriptor handy, so we might as well fill in the information at this point.
Reported-by: Tetsuo Handa [email protected] Cc: Al Viro [email protected] Acked-by: Eric Biederman [email protected] Signed-off-by: Linus Torvalds [email protected]
Created Text For URL [nationaldailyng.com/ebonyi-student-eats-poison-because-she-hears-female-voice-answers-phone-call-to-boyfriend/]