@cute_stuff right it is a leftover, probably there's some other options that no longer make sense. it used to vimscript, which i rewrote in lua without much thinking involved :-)

and whether it could be a reproducible ofc

i wonder if #linux #kernel could have a make target for #LSP, i.e. just for generating compile_commands.json for everything, like you had local #bootlin #elixir. in the current form i rather use git grep because it is at least more universal, whereas the json file is tied to the current .config.

While people tend to have complex #vim and #neovim configurations I just have this tiny one, less than 100 lines :-) It has served me for years with minor adjustments…

vim.cmd("filetype plugin indent on")
vim.cmd [[packadd packer.nvim]]

local function plugins(use)
  use 'wbthomason/packer.nvim'
  use 'ap/vim-buftabline'
  use {
    'nvim-lualine/lualine.nvim',
    requires = { 'kyazdani42/nvim-web-devicons', opt = true }
  }
  use 'Mofiqul/dracula.nvim'
  use 'mmarchini/bpftrace.vim'
  use 'vim-scripts/git_patch_tags.vim'
  use {
    'nvim-treesitter/nvim-treesitter',
    run = ':TSUpdate'
  }
  use {
    'VonHeikemen/lsp-zero.nvim',
    branch = 'v2.x',
    requires = {
      {'neovim/nvim-lspconfig'},
      {
        'williamboman/mason.nvim',
        run = function()
          pcall(vim.cmd, 'MasonUpdate')
        end,
      },
      {'williamboman/mason-lspconfig.nvim'},
      {'hrsh7th/nvim-cmp'},
      {'hrsh7th/cmp-nvim-lsp'},
      {'L3MON4D3/LuaSnip'},
    }
  }
end

require('packer').startup(plugins)

vim.g.mapleader = ","
vim.opt.autoindent = true
vim.opt.backspace = "indent,eol,start"
vim.opt.backup = false
vim.opt.clipboard = "unnamedplus"
vim.opt.compatible = false
vim.opt.completeopt = "menuone,noinsert,noselect"
vim.opt.hidden = true
vim.opt.history = 2000
vim.opt.hlsearch = true
vim.opt.incsearch = true
vim.opt.listchars="tab:>-,trail:·"
vim.opt.mouse = ""
vim.opt.path:append("**")
vim.opt.ruler = true
vim.opt.shortmess:append("c")
vim.opt.showmatch = true
vim.opt.swapfile = false
vim.opt.tags = "./tags;/"
vim.opt.termguicolors = true
vim.opt.wildmenu = true
vim.opt.wrap = false

if vim.g.neovide then
  vim.o.guifont = "FiraCode Nerd Font Mono:h12"
end

vim.api.nvim_create_autocmd(
  { "FocusGained", "BufEnter" },
  { pattern = "*", command = [[:checktime]],
    group = vim.api.nvim_create_augroup("BufCheck", { clear = true }) }
)

local function nmap(shortcut, command)
  local opts = { noremap = true, silent = true }
  vim.api.nvim_set_keymap('n', shortcut, command, opts)
end

nmap("<silent>", "<C-l> :nohl<CR><C-l>")
nmap("<leader>cd", ":lcd %:p:h<CR>:pwd<CR>")

vim.cmd[[colorscheme dracula]]
require('lualine').setup {
  options = {
    theme = 'dracula-nvim'
  }
}

in-kernel #keystone #driver in-progress (actually it is functioning but I need to separate from research project codebase) https://github.com/keystone-enclave/keystone/pull/328 #linux #kernel #riscv

CoVE won't fly in the upstream as a single company endeavour as it would dominate the whole ecosystem, if it would. This type of collaboration would make the whole thing factors more appealing. Leveraging is often better than replacing IMHO.

Neither is a stable hardware architecture so bottlenecks in that area are not excuse not to engineer things better.

My first impressions of RISC-V CoVE: I don't see why it couldn't made to leverage #keystone for attestation.

It already has a community and legit use cases, which cannot be satisfied by CoVE. Why create this divergence and not to engineer things work together, when you have a chance? #riscv #linux #kernel #cove

for C++, #riscv collab #toolchain’s seem to be broken (or could be that I’m doing something wrong) so:

1. For ELF (bare metal) and GLIBC targets I use whatever #ubuntu packages:

    sudo apt install {gcc,g++}-riscv64-linux-gnu \
                     linux-libc-dev-riscv64-cross

   CROSS_COMPILE is set to riscv64-linux-gnu-.

2. For #musl I use #riscv collab provided toolchain

It is not perfect but it is definitely sustainable at least…

#notetomyself: download and extract #riscv #toolchain:

echo elf glibc musl | xargs -n1 | xargs -I{} echo https://github.com/riscv-collab/riscv-gnu-toolchain/releases/download/2022.08.25/riscv64-{}-ubuntu-20.04-nightly-2022.08.25-nightly.tar.gz | xargs curl -sSL | tar zx -i

thinking of #chatgpt, i'm more interested what people can do with it, which previously was not possible, rather than what it can do previously performed by human labour.

doing factors faster previous science is not overwhelmingly interesting in the end.

this is sad and true unfortunately. https://lunduke.substack.com/p/microsofts-growing-control-of-linux #microsoft #linux #opensource #proprietary

Fetching a tag from #ubuntu #linux #kernel tree:

function git-fetch-linux-ubuntu-tag {
  local tag=refs/tags/cod/mainline/$1
  git fetch --no-tags \
    git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack \
    $tag:$tag
}

Usage example:

$ git checkout -b tmp
Switched to a new branch 'tmp'

$ git-fetch-linux-ubuntu-tag v6.3
From git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack
 * [new tag]                   cod/mainline/v6.3 -> cod/mainline/v6.3

$ git merge v6.3

Building:

LANG=C fakeroot debian/rules clean
LANG=C fakeroot debian/rules binary-headers binary-generic binary-perarch

still no idea how to remove duplicate emails, and the query language is not in par with mutt but benefits overcome these minor glitches :-)

thank you #mutt 1999-2023, i've now fully moved into #aerch as my main #email client. https://aerc-mail.org/

I like virt manager otherwise, except for its crappy looking icon :-) #kvm #qemu #libvirt

So to test my next branch I just need to do pretty trivial steps to get a properly packaged distro kernel:

git fetch --no-tags git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack refs/tags/cod/mainline/v6.3-rc7:refs/tags/cod/mainline/v6.3-rc7
git checkout next
git checkout -b next-test
git merge cod/mainline/v6.3-rc7
LANG=C fakeroot debian/rules clean
LANG=C fakeroot debian/rules binary-headers binary-generic 

In my experience even in archlinux test kernel packaging is more involved than ubuntu.

I favor Ubuntu in my machines because it has so streamlined kernel workflow, which lends itself to testing new upstream patches (even among Debian derivatives).

#remindertomyself: fetch a #git tag for the given #ubuntu #mainline #linux #kernel #snapshot:

$ git fetch --no-tags git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack refs/tags/cod/mainline/v6.3-rc7:refs/tags/cod/mainline/v6.3-rc7
From git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack
 * [new tag]                   cod/mainline/v6.3-rc7 -> cod/mainline/v6.3-rc7

suppilovahvero in linux-tpmdd on  next took 19s
$ git tag
cod/mainline/v6.3-rc7

Compilation:

LANG=C fakeroot debian/rules clean
LANG=C fakeroot debian/rules binary-headers binary-generic binary-perarch

#libreoffice #draw is the only reason why i install it in the first place anywhere. it provides equivalent user experience and robustness to all #subscription based #diagram tools, without the subscription fees.

the only thing i would improve in it would be t separate it from the rest of the suite because i don't have any use for the other libreoffice applications.