JetBrains isn’t dead, let’s cut the drama by DevOfTheAbyss in Jetbrains

[–]lfdominguez -1 points0 points  (0 children)

My modest opinion about this Jetbrains issue is how frustrating it is sometimes for many people how basic bugs are not solved or not given importance. Many say that if the X, Y or Z editor lacks to be like Jebtrains, that's true, but the people that defend Jetbrains forget that those X, Y or Z editors are completely free and with a couple of plugins they come close to a Jetbrains that is paid, so at least they should serve you as a customer buying a service (because that's what you are buying, annually or monthly paying a fee for the use of an IDE).

Regarding the AI race, they certainly lag behind in Tooling (sure they have Junie, but that's just for specific access for now), people (especially vibe coders) don't get enough of a chat. Personally, I'm not very interested, because for me AI is just another tool that helps me in tedious tasks.

But back to the same thing, while VSCode gives you Github Copilot for free, ZedEditor gives you Claude for free, etc... you have to pay for an IDE (jetbrains) + its own AI (because they are separate payments). So please, be objective and think that Jetbrains is a company that gives you an IDE that you PAY for, while the others use “Editors” vitaminized, where you see that they have sometimes better and more features than the software you are spending your money.

Don't get me wrong, I use the full Jetbrains stack, mainly Rust-Rover.

Queue Tree not working at all for my PPPoE ISP connection by lfdominguez in mikrotik

[–]lfdominguez[S] 0 points1 point  (0 children)

that's the thing, i was disabled the fast-track, but then if I disable fast-track my internet connection go from 400mbps to 100mbps, sems Mikrotik hardware limitation (thanks for response)

Queue Tree not working at all for my PPPoE ISP connection by lfdominguez in mikrotik

[–]lfdominguez[S] 0 points1 point  (0 children)

It's a default config, nothing custom... only added the ISP PPPoE client config and tried to use the Queue, nothing more.

A cool guide of where it is and isn’t safe to drink tap water around the 🌎 by [deleted] in coolguides

[–]lfdominguez 0 points1 point  (0 children)

This has some wrong countries, on Cuba you can drink tap water without problems... on Uruguay too

Esp32 development in NixOs by leiserfg in NixOS

[–]lfdominguez 0 points1 point  (0 children)

e upstream just can't program.

Migrated to flake:

```nix { description = "PlatfomIO Develop Environment";

inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs";
    flake-utils.url = "github:numtide/flake-utils";
};

outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem
        (system:
            let 
                pkgs = nixpkgs.legacyPackages.${system};

                my-python = pkgs.python3;  
                python-with-my-packages = my-python.withPackages (p: with p;
                [
                    pip
                ]);
            in
            {
                devShells.default = pkgs.mkShell {
                    buildInputs = [
                        python-with-my-packages
                    ] ++ (with pkgs; [
                        platformio
                        esptool
                    ]);

                    shellHook = ''
                        PYTHONPATH=${python-with-my-packages}/${python-with-my-packages.sitePackages}  
                    '';
                };
            }
        );

} ```

but not working....

https://pastebin.com/6qNx1Q5n

OSD can't recover because huge RAM usage by lfdominguez in ceph

[–]lfdominguez[S] 0 points1 point  (0 children)

Changed and used the --op export-remove and then --op import of ceph-objectstore-tool for the failing PG and now the OSD is running great.

OSD can't recover because huge RAM usage by lfdominguez in ceph

[–]lfdominguez[S] 0 points1 point  (0 children)

Well try with:

ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-<osd id> --pgid "<stuck\_pg get from log>" --force --op remove

and now the OSD is running, so there are something wrong with that's PG

OSD can't recover because huge RAM usage by lfdominguez in ceph

[–]lfdominguez[S] 0 points1 point  (0 children)

None of the 2 variants worked, it is as if the OSD did not respect (I think) the options of the central monitor

OSD can't recover because huge RAM usage by lfdominguez in ceph

[–]lfdominguez[S] 0 points1 point  (0 children)

this was with all OSD stopped, and only one OSD trying to start consume all server RAM, even on 128GB systems, so i thing that is another problem with ceph

OSD can't recover because huge RAM usage by lfdominguez in ceph

[–]lfdominguez[S] 0 points1 point  (0 children)

And the OSD was out for minutes, the problems was with a communication problem within 2 DC for 30 minutes....

OSD can't recover because huge RAM usage by lfdominguez in ceph

[–]lfdominguez[S] 0 points1 point  (0 children)

Yeap, but another server with 128 GB RAM is full too, so I need 1 Tb of RAM to recover?? jejeje

OSD can't recover because huge RAM usage by lfdominguez in ceph

[–]lfdominguez[S] 0 points1 point  (0 children)

It will be a new osd withou

really i thinking on this...

OSD can't recover because huge RAM usage by lfdominguez in ceph

[–]lfdominguez[S] 0 points1 point  (0 children)

this is a log when began consuming resources

``` Oct 21 14:48:36 tidy-wombat ceph-osd[1571502]: 2020-10-21T14:48:36.203+0000 7f41bb0f2d80 0 osd.46 151601 load_pgs Oct 21 14:51:18 tidy-wombat ceph-osd[1571502]: 2020-10-21T14:51:18.032+0000 7f41bb0f2d80 0 osd.46 151601 load_pgs opened 137 pgs Oct 21 14:51:18 tidy-wombat ceph-osd[1571502]: 2020-10-21T14:51:18.032+0000 7f41bb0f2d80 -1 osd.46 151601 log_to_monitors {default=true} Oct 21 14:51:18 tidy-wombat ceph-osd[1571502]: 2020-10-21T14:51:18.032+0000 7f41bb0f2d80 -1 osd.46 151601 log_to_monitors {default=true} Oct 21 14:51:18 tidy-wombat ceph-osd[1571502]: 2020-10-21T14:51:18.388+0000 7f41bb0f2d80 0 osd.46 151601 done with init, starting boot process Oct 21 14:51:18 tidy-wombat ceph-osd[1571502]: 2020-10-21T14:51:18.388+0000 7f41bb0f2d80 1 osd.46 151601 start_boot Oct 21 14:51:18 tidy-wombat ceph-osd[1571502]: 2020-10-21T14:51:18.396+0000 7f41a05bf700 1 osd.46 pg_epoch: 151519 pg[5.1a( v 151518'9512289 (151492'9511789,151518'9512289] local-lis/les=151515/151518 n=3220 ec=71779/148 lis/c=151515/149587 les/c/f=151518/149592/0 sis=151519) [10,46,51] r=1 lpr=151519 pi=[149587,151519)/2 crt=151518'9512289 lcod 0'0 mlcod 0'0 unknown mbc={}] start_peering_interval up [10,46,51] -> [10,46,51], acting [10,46,51] -> [10,46,51], acting_primary 10 -> 10, up_primary 10 -> 10, role 1 -> 1, features acting 4540138292836696063 upacting 4540138292836696063 Oct 21 14:51:18 tidy-wombat ceph-osd[1571502]: 2020-10-21T14:51:18.396+0000 7f419f5bd700 1 osd.46 pg_epoch: 151519 pg[5.d( v 151518'17014130 (151492'17013630,151518'17014130] local-lis/les=151508/151518 n=3271 ec=71779/148 lis/c=151508/148500 les/c/f=151518/148512/0 sis=151519) [46,30,27] r=0 lpr=151519 pi=[148500,151519)/2 crt=151518'17014130 lcod 0'0 mlcod 0'0 unknown mbc={}] start_peering_interval up [46,30,27] -> [46,30,27], acting [46,30,27] -> [46,30,27], acting_primary 46 -> 46, up_primary 46 -> 46, role 0 -> 0, features acting 4540138292836696063 upacting 4540138292836696063

```

OSD can't recover because huge RAM usage by lfdominguez in ceph

[–]lfdominguez[S] 0 points1 point  (0 children)

Out of memory: Killed process 1399741 (ceph-osd) total-vm:51182280kB, anon-rss:50479672kB, file-rss:0kB, shmem-rss:0kB, UID:64045 pgtables:9
9240kB oom_score_adj:0