tugo

Можно сделать при момощи 9-patch картинки

border-image:  url(":/button.9.png");
border-width: 5px;

Почему хабражители предпочитают велосипеды, вместо...
Systemd для продолжающих. Part 1 — Запуск юнитов п...
Systemd для продолжающих. Part 2 — Триггеры на раз...

Основной недостаток использования Cgo - это снижение производительности.
Вызовы C/C++ достаточно затратны по ресурсам, т.к. C ничего не знает о данных в Go и для вызова C необходимо полностью сохранять все регистры и переключать стек, за счёт этого и возрастают накладные расходы, соответственно снижается производительность.

Использование Cgo имеет смысл, когда есть объёмные библиотеки написанные на C/C++, которые можно использовать. При этом написание кода на чистом Go намного затратнее, чем использование этих библиотек с Cgo.

> в каких кейсах следует использовать cgo для улучшения производительности
На сколько я понимаю при вызове простых функций производительность не улучшится, а наоборот, скорее ухудшится.
Но не исключаю, что есть кейсы, когда есть серьёзные расчёты/жёсткое управление памятью (частые выделения/освобождения), когда за счёт того, что в этом случае не будет использован сборщик мусора можно получить увеличения производительности.

У меня был подобный кейс на Perl, но принцип тот же.
При скачивании HTML страниц размер занимаемой RAM скриптом постоянно увеличивался и в итоге "съедал" всю память на сервере.

Задача скрипта была скачивать HTML страницы, извлекать из них все ссылки на внешние ресурсы.
Я принял решение и написал функцию на С, которая выкачивала страницу, извлекала ссылки, очищала память и возвращала в Perl уже готовый список ссылок. Скрипты перестали постоянно "пухнуть", их можно было запустить в несколько раз больше по количеству на том же сервере + производительность стала явно выше.

В общем всё сильно зависит от задачи, но, думаю, более 90% кейсов будет связано с тем, что намного дешевле использовать готовую библиотеку C/C++ с Cgo, чем переписать эту библиотеку на чистом Go.

есть мнение что чем 'крупнее и солиднее' компания, то тем скучнее работать в ней, так как каждый участник больше винтик в системе, которого даже обучать нет смысла, - 'занимаешь место, выполняешь необходимую задачу, затраты по сравнению получаемыми доходами приемлимые - так зачем это менять?'.

Попробуй обратись к своему начальнику с предложением дать другое задание, тебе это нужно для самосовершенстовования, и лучше это делать на деньги работодателя, а не свое время.

Для скрипта никак. Придётся писать обёртку на компилируемом языке, которая вызовет функции setuid и setgid, а затем запустит скрипт. На бинарник обёртки уже можно поставить флаг S как написал Александр Карабанов. Пример обёртки:

#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>

int main() {
  setuid(0);
  setgid(0);
  system("/path/to/script");
}

При этом естественно владельцем файла должен быть пользователь чьи права нужно получить. То есть для данной обёртки нужно выполнить chown root:root /path/to/file. Правда программа с UID==0, может установить себе любой UID. Вот так вот и работают sudo и su.

Попробуй setuid бит chmod u+s <filename>
Исполняемый файл с установленым setuid битом запускается c правами владельца, если это root, то от root.
Но это дыра в безопасности...

Есть ещё setgid chmod g+s <filename> запускать от имени группы, возможно он подойдёт лучше. Или нет...

Если не подойдёт, то удалить биты можно заменив "+" на "-":
chmod u-s <filename>
chmod g-s <filename>

PS
Собсвенно sudo и позволяет повышать привилегии за счёт установленного setuid бита:

~$ which sudo
/usr/bin/sudo
~$ ls -alah /usr/bin/sudo
-rwsr-xr-x 1 root root 163K янв 19  2021 /usr/bin/sudo
~$

-rwsr-xr-x это и есть setuid бит.